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BACKGROUND  INFORMATION  ON  THE  WORKSHOP 

The  International  Purdue  Workshop  on  Industrial  Computer 
Systems,  in  its  present  format,  came  about  as  the  result  of  a 
merger  in  1973  of  the  Instrument  Society  of  America  (ISA)  Com- 
puter Control  Workshop  with  the  former  Purdue  Workshop  on  the 
Standardization  of  Industrial  Computer  Languages,  also  co- 
sponsored by  the  ISA.  This  merger  brought  together  the  former 
workshops'  separate  emphases  on  hardware  and  software  into  a 
stronger  emphasis  on  engineering  methods  for  computer  projects 
Applications  interest  remains  in  the  use  of  digital  computers 
to  aid  in  the  operation  of  industrial  processes  of  all  types. 

The  ISA  Computer  Control  Workshop  had  itself  been  a re- 
naming in  1967  of  the  former  Users  Workshop  on  Direct  Digital 
Computer  Control,  established  in  1963  under  Instrument  Society 
of  America  sponsorship.  This  Workshop  in  its  annual  meetings 
had  been  responsible  for  much  of  the  early  coordination  work 
in  the  field  of  direct  digital  control  and  its  application  to 
industrial  process  control.  The  Purdue  Workshop  on  Standardi- 
zation of  Industrial  Computer  Languages  had  been  establsihed 
in  1969  on  a semiannual  meeting  basis  to  satisfy  a widespread 
desire  and  need  expressed  at  that  time  for  development  of 
standards  for  languages  in  the  industrial  computer  control 
area. 

The  new  combined  international  workshop  provides  a forum 
for  the  exchange  of  experiences  and  for  the  development  of 
guidelines  and  proposed  standards  throughout  the  world. 
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Regional  meetings  are  held  each  spring  in  Europe,  North 
America  and  Japan,  with  a combined  international  meeting  each 
fall  at  Purdue  University.  The  regional  groups  are  divided 
into  several  technical  committees  to  assemble  implementation 
guidelines  and  standards  proposals  on  specialized  hardware 
and  software  topics  of  common  interest.  Attendees  represent 
many  industries,  both  users  and  vendors  of  industrial  compu- 
ter systems  and  components,  universities  and  research  insti- 
tutions, with  a wide  range  of  experience  in  the  industrial 
application  of  digital  systems.  Each  workshop  meeting  fea- 
tures tutorial  presentations  on  systems  engineering  topics  by 
recognized  leaders  in  the  field.  Results  of  the  workshop  are 
published  in  the  Minutes  of  each  meeting,  in  technical  papers 
and  trade  magazine  articles  by  workshop  participants , or  as 
more  formal  books  and  proposed  standards.  Formal  standardi- 
zation is  accomplished  through  recognized  standards-issuing 
organizations  such  as  the  ISA,  trade  associations,  and 
national  standards  bodies. 


The  International  Purdue  Workshop  on  Industrial  Computer 
Systems  is  jointly  sponsored  by  the  Automatic  Control  Systems 
Division,  the  Chemical  and  Petroleum  Industries  Division,  and 
the  Data  Handling  and  Computations  Division  of  the  Instrument 
Society  of  America,  and  by  the  International  Federation  for 
Information  Processing  as  Working  Group  5.4  of  Technical 
Committee  TC-5. 


The  Workshop  is  affiliated  with  the  Institute  of  Electrical 
and  Electronic  Engineering  through  the  Data  Acquisition  and  Con- 
trol Committee  of  the  Computer  Society  and  the  Industrial  Control 
Committee  of  the  Industrial  Applications  Society,  as  well  as  the 
International  Federation  of  Automatic  Control  through  its  Com- 
puter Committee. 


ORIGIN  OF  GUIDELINES 


This  is  a reprint  of  the  set  of  guidelines  developed  by  the  Man/Machine 
Conmunications  Committee  of  the  International  Purdue  Workshop  on  Industrial 
Computer  Systems. 
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DISCLAIMER 


The  committee  recognizes  that  the  present  form  of  the  Guidelines 


raises  more  questions  than  it  answers.  This  is  because  its  original 


intention  is  to  provide  the  designer  only  with  a proper  state  of 


mind 


one  which  prepares  him  for  receiving  useful  information 
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rather  than  the  information  itself!  Also,  the  term  "man 


as  a convenience  terra  to  imply  operator,  person,  humain  or  mankind 


whenever  the  latter  terms  could  have  heen  more  specifically  utilized 
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INTRODUCTION 


The  growing  use  of  computer  control  systems  with  their  large  information 
and  control  data  bases  is  focusing  increasing  attention  on  the  problem 
of  interfacing  the  human  operator  in  the  system  with  the  process  and  the 
control  computer.  There  is  much  that  remains  to  be  learned  about  the 
optimum  coordination  of  men  and  machines,  and  the  need  to  specify  and 
design  operating  interfaces  is  a current  problem  in  every  process  con- 
trol project. 

There  is  a need  for  a systematic  approach  to  the  design  of  raan/machine 
interfaces.  These  guidelines  are  an  attempt  to  provide  am  orderly 
thought  process  for  the  ultimate  specification  of  an  effective  MMIF, 
or  operator's  console,  as  opposed  to  the  details  of  implementation.  It 
is  intended  to  be  both  process  and  interface  device  independent. 

The  guideline  is  organized  in  a "top-down"  format.  The  primary  deci- 
sions relating  to  the  overall  scope  of  the  job  to  be  performed  are 
examined  first.  Out  of  this  top-level  view,  the  requirements  that  im- 
pinge upon  interface  design  are  identified  and  \iltimately  combined  with 
human  factors  engineering  to  create  a functional  specification. 

To  provide  a frame  of  reference,  a Man/Machine  System  Model  is  postu- 
lated which  is  diagrammed  in  Figure  i.l.  Two  important  subsystems  are 
defined: 

The  personnel  subsystem 
The  machine  subsystem 

The  Man/Machine  Interface  (MMIF)  is  that  boundary  between  the  two  sub- 
systems across  which  information  and  control  manipulation  flows.  In 
physical  terras,  it  is  typically  the  face  of  a console  which  contains 
displays  and  keyboards  of  various  types.  The  hardware  and  software 
behind  this  boundary  participates  in  translating  human  inputs  to  control 
signals  and  process  inputs  into  data  displays  for  hiomans.  It  will  be 
termed  the  Man/Control  System  Translator.  The  boundary  between  this 
translator  and  the  computer  is  called  the  Man/Computer  Interface  or 
MCIF.  In  a similar  fashon,  we  have  the  Process/Computer  Translator,  and 
the  Process/Computer  Interface,  or  PCIF. 

The  guidelines  develop  an  approach  which: 

1.  Reviews  the  objectives  of  an  overall  system  operation  and 
helps  identify  a set  of  constraints  for  the  process  and  per- 
sonnel subsystems. 

2.  Identifies  important  characteristics  of  the  operations  control 
center  relevant  to  the  system's  constrained  objectives. 
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3.  Identifies  important  characteristics  of  the  human  operator 
relevant  to  the  control  center. 

4.  Identifies  the  important  functional  characteristics  of  the 
MMIF. 

5.  Considers  implementation  techniques  of  the  MMIF  from  consi- 
deration of  these  functional  requirements. 


THE  HAN-HACHINE  SYSTEM  MODEL 


PERSONNEL  SUBSYSTEM 


MACHINE  SUBSYSTEM 


MMIF' 


CONTROL 


FIGURE  i.l 
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PURPOSE  AND  SCOPE 

Purpose: 

The  purpose  of  this  document  is  to  serve  as  a guideline  for  j 

the  definition  of  a computer-directed  process  control  opera- 
tor’s interface.  This  interface  will  be  defined  as  the 
"Man/Machine  Interface",  or  MCF. 

Scope : 

This  guideline  is  intended  to  be  both  process  and  device 
independent.  It  deals  with  the  functional  requirements  of  the 
interface  and  the  corresponding  functional  methods  of 
impl ement  at i on . 

The  guideline  is  organized  in  a "top-down  format.  The  high 
level  and  primary  decisions  relating  to  the  functions  to  be 
performed  are  examined  first.  From  this,  the  MMIF  require- 
ments may  finally  be  defined  and  specified. 
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HOW  TO  THINK  ABOUT  YOUR  MMIF  DESIGN  TASK 
Key  Points  of  Guideline 
(Referenced  by  Section  Nimiber) 


1.  (0.0)  TOP  DOCUMENT 

Th--'  Committee  views  this  Guideline  as  the  TOP  DOCUliENT  (hitherto  un- 
available) for  MMIF  guideline  literature: 

Total  riMIF 
Guideline 
Literature 

Others  (SUPPORTIVE)  - Details;  Configuration 

This  Guideline  outlines  a SYSTEMATIC  THOUGHT  PROCESS  for: 

(1)  Identifying  the  STARTING  POINT  for  design  (which  varies  with 
application:  one  can  enter  this  process  wherever  suitable); 

(2)  Establishing  a CONCEPTUAL  design  approach; 

(3)  Producing  a FUNCTIONAL  design; 

and  (i<)  Determining  a METHOD  for  IMPLEMENTING  it. 

2.  (0.0)  PROCESS/DEVICE  INDEPENDENT 

Hense  this  Guideline  is  APPLICATION  (process/device)  INDEPENDENT. 

Other  references  (see  bibliography)  provide  guidelines  for  CONFIGURING 
a functional  design  for  a particular  APPLICATION  (spacing  of  keys, 
size  of  displays,  etc.). 


They  are  SUPPORTIVE  of  this  Guideline  and  should  be  used  with  it. 
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3.  (U.O)  INFORiVtATION  EXCHANGE 

The  MI^IF  implements  an  INFORMATION  EXCHANGE  between  MAN  AND  PROCESS; 


Man 


INFORMATION 


Process 


3 functions  are  involved: 

(1)  GENERATION  of  information  from  process  data 

(2)  PRESENTATION  of  information  to  man 

(3)  MANIPULATION  of  information  by  man 
(0.0)  2 MACHINES,  3 LANGUAGES,  3 TRANSLATORS 

The  term  "man-machine-interface"  is  generic.  In  process  control 
2 MACHINES  are  involved; 

(1)  CONTROL  SYSTEM 

(2)  PROCESS 


CONTROL  SYSTEM 


INFORMATION 


Hence,  3 LANGUAGES  are  present 


CONTROL  SYSTEM 


PROCESS 


requiring  3 TRANSLATORS,  which  are  3 VERSIONS  of  the  MMIF 


CONTROL  SYSTEM 
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I 

i 

(1)  CONTROL  SYSTEM/PROCESS  Interface  - translates  process  - | 

( 

sensed  signals  into  Control  System  internal  signals;  ! 

I 

(2)  MM/CONTROL  SYSTEM  Interface  - translates  Control  System  j 

i 

internal  signals  into  hiiman  displays  and  controls;  ^ 

(3)  MAN/PROCESS  Interface  - entire  control  system  considered  as  I 

translator.  i 

* TRANSPARENCY 

* OVERRIDING  OBJECTIVE  of  MMIF  design  is  a completely  TRANSPARENT 
MAN/PROCESS  TRANSLATION. 

* AVOID  IMPOSING  TRANSLATOR  CHARACTERISTICS  on  the  information  exchange. 

6.  (0.0)  TOP-DOWN  APPROACH 

Achieve  this  objective  by  a TOP-DOWN  approach  to  design: 

(1)  NEEDS  FIRST  - define  the  problem  before  choosing  the  solution; 

(2)  CONCEPT  FIRST  - a well-thought-out  concept  begets  details  which 
are  CONSISTENT  and  COMPLIMENTARY  to  it;  changes  are  EVOLUTIONARY 
EXTENSIONS  of  it; 

I 

(3)  AVOID  "UPSIDE-DOWN"  design  - the  inverse  of  (l)  and  (2)  wherein  • 


7. 


details  and  changes  define  a new  concept. 
(3.0)  k PHASES 


This  approach  has;  4 PHASES  (see  Figure  3.1): 

^ Identify  REQUIREMENTS  (social,  legal,  environmental,  management 
policies,  etc.)  of  4 elements  of  MMIF: 

(1)  Personnel 

( 2 ) Plant  management 

(3)  Control  system  instrumentation 

(4)  Process  behavior; 


r 
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II  Allocate  FUNCTIONS  among  MAN  (personnel)  and  MACHINE  (control 
system) ; 

III  Analyze  TASKS  to  perform  functions; 

IV  Produce  FUNCTIONAL  design;  determine  method  of  IMPLEMENTING 
it . 

T.  (1.0)  PERSONNEL 

PLANT  MANAGEMENT  objectives  increasingly  affect  CONTROL  STRATEGY 
and  the  number,  type  and  role  of  PEOPLE  involved. 

8.  (l.Q)  UNPREDICTICALITY 

UNPREDICTABLE  aspects  of  process  behavior  are  often  best  handled 
through  man's  JUDGEMENTAL  and  adaptive  capabilities. 

9.  (1.0)  PACING 

Does  man  PACE  process  (and  control  system),  or  vice-versa?  BOTH 
can  be  applicable  - MAIi  PACES  during  startup;  MACHINE  PACES  during 
normal  running. 

Can  man  ANTICIPATE  process  behavior  or  only  REACT? 

10.  (2.2)  ENVIRONMENTAL  PARADOX 

The  MMIF  is  usually  physically  bounded  by  the  CONTROL  ROOM;  its 
ENVIRONMENTAL  ASPECTS  are  a MAJOR  VARIABLE  in  MMIF  performance. 
PARADOXICALLY,  man  and  control-system  both  CONTRIBUTE  TO  (noise, 
etc.)  and  must  be  ACCOMMODATED  BY  (temperature  controls,  etc.)  this 
environment.  Control  room  ARCHITECTURE  and  VISUAL  APPEARANCE  are 
extremely  important  factors;  it  is  NOT  SUFFICIENT  to  place  the  ?iMIF 
in  ANY  OLiD  ROOM. 

11.  (3.0)  WEDDINGS 

SUCCESSFUJ.  MMIF  design  are  successful  WEDDINGS  of  human  factors 
engineering  (HFE)  and  control  system  engineering  (CSE). 


HFE  WEDS  man  to  machine  and  vice-versa. 

CSE  WEDS  process  to  instrumentation  and  vice-versa. 

MMIF  functional  and  physical  design  expresses  TASK  ALLOCATION 
between  man  and  control  system. 

12.  (t*.0)  TASK/ TECHNIQUE/DEVICE 

3 STEPS  in  a METHOD  of  determining  the  APPROACH  to  physically 
IMPLEMENTING  the  FUNCTIONAL  design  for  information  PRESENTATION  and 
MANIPULATION; 

(1)  Specify  the  TASK  (for  example  display  setpoint); 

(2)  Determine  ALTERNATE  TECHNIQUES  to  accomplish  task; 

(3)  Identify  ALTERNATE  DEVICES  to  implement  technique. 

* REMEMBER : 

* ALTERNATES  are  ALWAYS  AVAILABLE. 

* there  is  NEVER  only  ONE  solution. 

13.  (6.0)  FULFILLMENT 

This  Guideline's  TOP  DOCUMENT  role  is  FULFILLED  after  completing 
Section  1.0: 

(1)  All  man-  and  machine-dependent  REQUIREMENTS  are  identified; 

(2)  A design  CONCEPT  is  established; 

(3)  It  is  expressed  in  a FUNCTIONAL  design; 
and  (U)  An  IMPLEMENTATION  APPROACH  is  established. 

Now  refer  to  SUPPORTIVE  sources  (see  bibliography).  DETAIL  the  imple- 


mentation to  your  APPLICATION. 
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OUTLINE  OVERVIEW 


1.0  Overall  Operation  Requirements 

Process  and  Personnel  requirements  are  reviewed  to  determine  all 
of  the  aspects  that  will  specify  or  restrict  the  objective  to  be 
accomplished  by  the  man/machine  interface. 

1.1  Process  Requirements 

1.2  Personnel  Requirements 

2.0  Control  Center  Requirements 

Management  and  Environmental  requirements  that  may  lead  to  require- 
ments and  restrictions  on  the  Control  Center  itself  are  enumerated. 

2.1  Management  Requirements 

2.2  Environmental  Factors 

3.0  Man/Machine  Interface  Design  Factors 

A series  of  questions  and  statements  are  listed,  which  when  answered, 
provides  a restricted  set  of  requirements  for  the  man/machine  inter- 
face. The  questions  and  statements  cover  process,  management,  human 
factors  and  functional  requirements. 

3.1  Organization  of  the  Design  Approach 

3.2  Human  Factors  Engineering 

3.3  Translator  Functional  Requirements 
k . 0 Impl ement  at i on 

Various  methods  of  implementing  the  man/machine  interface  are 
discussed. 

^4.1  Scope 

h.2  Presentation 

b.3  Manipulation 

5.0  Glossary 

6.0  Bibliography 
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1.0  OVERALL  OPERATIONS  REQUIREMENTS 


Overall  system  operations  are  first  examined  to  determine  those 
requirements  which  will  define  or  restrict  the  objectives  which  are 
to  be  accomplished  by  the  Man/Machine  Interface.  This  procedure  is 
exemplified  by  the  Guideline  Flow  chart  of  Figure  1.0. 

1.1  Process  Requirements 


The  first  step  in  the  design  of  an  MMIF  should  be  to  collect 
as  much  pertinent  information  as  possible  about  the  process  to 
be  controlled.  Considering  the  items  mentioned  in  this  sec- 
tion will  be  useful  in  collecting  this  information. 

-1  Process  Stability  and  Predictability 

The  primary  reason  for  including  a human  in  the  system  is 
to  handle  unpredictable  aspects  of  the  process.  This  is 
closely  related  to  stability  since  \instable  processes 
(such  as  those  containing  exothemic  reactions)  will 
amplify  the  effects  of  unpredictable  events. 

Some  typical  sources  of  uncertainty  are: 

Equipment  malfunction 
Utility  failure 

Variability  of  raw  materials,  utilities,  weather 
Process  disturbances  or  upsets 
Lack  of  complete  process  knowledge 
Sudden  poisoning  of  a catalyst  (as  opposed  to 
gradual  degradation) 

Accommodation  of  the  process  for  unusual  situations 
in  equipment  availability,  energy  availability, 
polution  control,  etc. 

Sensing  of  system  behavior  or  characteristics  for 
which  no  automatic  sensors  are  provided 
Variables  not  subject  to  automatic  measurement 
"Special"  or  "unrehearsed"  runs 

On  the  other  hand  some  sources  of  variability  are  readily 
predictable  and  may  not  need  human  intervention  to  com- 
pensate. Typical  of  these  are  gradual  fouling  of  heat 
exchanges  and  gradual  changes  in  catalyst  activity. 

Variables  To  Be  Measured 

All  variables  to  be  measured  should  be  listed  and  described 
in  detail.  For  most  variables  the  description  should 
include: 

- Normal  Variables 


Type  of  sensor 

Response  time  and  consistency  of  response 
Need  for  trend  and  historical  data 
System  inertia 
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Expected  noise  and/or  error 
Desired  engineering  units 
Variables  derived  by  calculation 
Expected  range 

Alarm  settings  and  required  action 
Range  and  source  of  set  points 
Possible  overides  of  constraints 

In  addition,  variables  which  are  difficult  to 
measure  often  require  very  special  interface  consi- 
derations. For  example,  a variable  which  requires 
a manual  laboratory  type  analysis  needs  a defined 
means  of  entering  data  into  t he  system.  On  some 
important  variables  it  may  be  worthwhile  to  check 
them  by  correlating  them  with  other  variables. 

Mode  of  Operation 

A process  may  operate  continuously  or  in  a batch 
mode.  There  is  often  a choice  between  the  two  which 
is  closely  related  to  the  control  needs  and  to  the 
MMIF. 

Is  it  a series  or  a parallel  process? 

Does  the  process  have  a n\mber  of  parallel  branches? 
How  many  steps  are  in  series  and  what  is  available 
or  required  to  surge  between  steps? 


(examples ) 

a. 

The  above  questions  can  have 
an  important  bearing  on  the  dis- 
tribution of  m\iltiple  control 
interfaces. 

b. 

Required  surge  may  sometimes  be 
reduced  by  careful  consideration 
of  interface  requirements. 

Outside  Constraints  and  Legal  Requirements 

The  constraints  placed  on  the  process  or  on  the  inter- 
face must  be  defined.  These  include  policies,  regula- 
tions, practices,  or  other  restrictions  imposed  by 
management,  government  or  unions. 

For  example,  management  or  sometimes  government  may 
require  storage  of  historical  data.  Union  rules  may 
restrict  permissible  operator  duties  and  working 
hours.  Any  of  them  may  impose  constraints  relating 
to  safety. 
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Operating  Objectives 

The  overall  objective  of  the  process  should  be 
carefully  defined  and  related  to  the  operator's 
duties. 

The  most  common  objective  is  to  produce  a product 
at  maximum  profit.  For  this  purpose  the  operator's 
scope  of  authority  must  be  defined  and  used  in  de- 
termining what  information  is  to  be  available  and 
what  range  of  control  is  permissible.  In  many 
situations  the  operator  has  a free  reign  on  variables 
, which  effect  product  quality  but  is  constrained  at 

points  limited  by  safety  considerations. 

1 A quite  different  objective  is  in  scientific  experi- 

I mentation.  Here  providing  flexibility  is  often  the 

most  important  consideration  at  the  MMIF. 

Other  possible  objectives  to  be  considered  are  training, 
safety,  and  pollution  control. 

Measures  of  Performance 

^fhat  are  the  measurements  of  performance  of  the  pro- 
cess, and  what  information  does  the  operator  need 
j from  them  for  optimization? 

Consideration  should  be  given  to  uiiisual  measure- 
ments, often  relating  to  product  quality  and  which 
may  require: 

-Information  from  remote  lab  or  locally  conducted 
lab  tests. 

-Human  judgement  of  product  taste,  smell,  or  other 
directly  observable  characteristics. 

-Customer  or  user  feedback. 

Environmental  Effects 

What  effect  does  Meteorology  have  on  the  process? 

(examples)  a.  Temperature  of  a cooling-water 

system  may  change  optimum  control 
strategy. 


b.  Air  humidity  is  important  in  a 
drying  application. 
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c.  A sudden  rainstorm  can  cause 
severe  disturbances  in  some  pro- 
cesses . 

d.  A violent  storm  can  cause  loss  of 
information  remoted  via  telephone 
or  microwave  links. 

Physical  Size  and  Layout 

The  physical  size  and  layout  of  the  process  are  very 
important  to  the  MMIF  requirements.  A process  which 
has  everything  written  the  operators  need  or  view 
will  have  substantially  different  communication  and 
interface  requirements  than  one  which  is  spread  over 
a larger  or  otherwise  non-viewable  area. 

Provisions  should  also  be  made  for  possible  future 
expansion  of  the  plant. 

1.1.2  Process  Controls 

The  desired  control  of  a process  is  directly  dependent  on 
the  proper  operation  of  the  hardware  and  software  used  to 
gather  and  display  the  process  parameters  of  interest. 

Process  Control 

The  objective  of  each  control  loop  should  be  studied 
and  related  to  the  plant  objectives  and  to  the 
operator's  duties. 

Where  complex  control  algorithms  and  strategies  are 
used,  thought  must  be  given  to  the  degree  of  under- 
standing needed  by  the  operator.  Is  it  necessary  to 
understand  the  process,  the  strategy,  or  just  the 
tiMIF?  In  some  cases  it  may  be  beneficial  to  display 
complex  control  schemes  schematically  for  the  opera- 
tor, the  supervisor  or  the  engineer.  Complex  schemes 
include  such  things  as  adaptive  or  multivariable 
control  or  a change  of  algorithm  depending  upon 
conditions. 

With  a display  it  is  feasible  to  spell  out  emergency 
recovery  procedures.  The  value  of  this  should  be 
considered. 

It  is  important  to  consider  the  consequences  of 
control  system  failure  in  terms  of  important  process 
variables,  unit  and  plant  integrity,  and  personnel 
safety.  Provisions  for  fail-safe  operation,  manual 
or  automatic  backup,  or  redundancy  must  be  studied. 

Plant  startup  and  shutdown  imposes  special  require- 
ments on  the  control  system.  Planned  frequency  of 
shutdown  influences  M>'r?  design.  There  may  be 
economic  or  safety  justification  for  some  automatic 
sequencing  of  startup  and  shutdown  operations. 


Special  Functions 

Various  aspects  of  system  performance  pertaining  to 
the  control  system  can  typically  be  tested  and  moni- 
tored on-line.  These  might  include: 

Proper  operation  of  analog  and/or  digital 
filters. 

Inactivating  a loop  on  line  in  order  to  cali- 
brate sensors  (e.g.  gas  analyzers,  amplifiers 
in  the  signal-computer  interface,  etc.) 

Deliberate  load  or  setpoint-pulsing  of  system, 
on  line,  to  optimize  controller  settings, 
obtain  loop  frequency  responses,  etc. 

Deliberate  changing  (or  sweeping)  of  controlled 
variables  to  obtain  wide-ranging  data  base 
needed  for  model  generation  or  updating. 

On  line  frequency  analysis  of  data  for  purposes 
of  evolving  inputs  to  control  schemes.  Post 
mortem  analysis  and  reporting  to  and  in  the 
analysis  of  a system  failure. 

Variables  to  be  Displayed 

The  consideration  of  the  above  functioning  of  pro- 
cess controls  then  logically  leads  to  the  variables 
of  the  process  that  should  be  displayed  and  mani- 
pulated. 

All  variables  to  be  measured  and  associated  with  the 
operation  of  controls  should  be  listed  and  described 
in  detail.  These  variables  might  include: 

Operator's  feedback  indications  of  hardware 
controller  setpoint,  gain,  reset,  and/or  rate 
settings. 

Indication  of  above  parameters  (and  addresses 
for  digital  control  algorithms. ) 

Valve  position  indication  (control  valves, 
scanning  valves,  etc.) 

Relay  status. 

Hardware  controller  status  (Computer-mode, 
local-mode,  bypassed,  etc.) 
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Computer-Process  hardware  interface  status 
(e.g.  is  process  interface  generating  pulses, 
shorted  out,  etc. ) 

Hardware-controller  utility  status  (instrument 
air  pressure,  power  supply  voltages,  steam 
pressure  and/or  temperature). 

Electrical  continuity  of  all  hardware  status 
alarm  lights.  (Lamp  Test) 

Descriptions  of  the  variables  should  include 
consideration  of  response  time,  type  of  sensor, 
expected  range,  ala;-m  settings  and  required 
action,  range  and  source  of  setpoints,  and 
possible  overrides  of  constraints. 

Some  control  schemes  have  special  legal  re- 
quirements (e.g.  supervisory  setpoint-control 
override  during  emergencies). 

Schematics  of  the  control  loops  may  be  desired 
for  display. 

Data  that  is  displayed  should  indicate  the 
validity  of  the  measurement.  The  display 
should  indicate  in  some  manner  if  the  variable 
exceeds  the  sensor  limits  (a  truly  bad  signal) 
If  the  measurement  for  some  reason  is  not  being 
scanned,  the  variables  should  be  so  indicated. 
In  any  event,  some  indication  of  the  measure- 
ment scanning  speed  (or  starting  and  stopping 
point)  should  be  available  on  the  display). 

.2  Personnel  Requirements 

The  overall  operations  review  will  impose  certain  "top-down" 
personnel  requirements.  The  following  section  will  go  into 
detail  about  their  needs. 

-1  Who  uses  the  console? 

There  are  many  facets  to  be  considered  in  this  section. 

It  is  not  enough  to  merely  say  the  operators  are  going  to 
control  the  process  from  this  console.  (For  purposes  of 
discussion  in  this  section,  anyone  who  uses  the  MMTF  is 
considered  to  be  the  "operator",  although  in  reality  he 
could  be  any  of  the  following  types  of  personnel.) 

- Process  Operator 

The  console  operator  or  operators  must  use  this 
console  as  their  communication  with  the  proce.ns.  The 
unit  must  be  designed  to  comfortably  fit  the  user/or 
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users.  Don't  skimp  - if  more  than  one  operator  will 
spend  considerable  time  at  the  console,  dual  entry  and 
displays  should  be  considered.  The  tasks  to  be 
performed  should  be  enumerated. 

(examples)  -changing  controller  set  points 
-activating  control  loops 
-increasing  or  decreasing  plant  throughput 
-putting  computer  on  or  off  control 
-updating  computer  with  lab  results 
-changing  recipe  amounts  when  permitted 
-running  equipment  or  process  tests  or 
diagnostic  routines 
-changing  console  operating  mode 


- Engineer 


Is  an  engineer,  or  a foreman,  or  other  persons 
in  charge  of  th'  operators?  Are  there  operational 
changes  to  be  entered  into  the  system  that  are  not 
the  responsibility  of  the  operator?  Are  there 
restrictions  or  operational  goals  imposed  on  the 
system?  Will  the  foreman  be  making  these  changes? 

What  percentage  of  the  time  will  this  console  be 
used  for  work  of  this  type?  This  will  vary  from 
industry  to  industry.  Thought  should  be  given  as  to 
where  this  type  of  input  shoxild  be  accomplished. 
Should  a particular  panel  or  section  be  reserved  for 
this  use?  Should  this  function  be  removed  to  a 
separate  location,  or  simply  locked-out  by  special 
keys  or  command-codes? 


- Supervisor 


Does  the  plant  supervisor  have  a need  for  obtaining 
special  data  or  data  arranged  in  a particular  way 
that  would  be  used  for  Management  decisions.  Where 
and  how  often  will  this  function  be  required?  Will 
a lock-out  be  required? 


- Programmer 


After  system  is  installed,  where,  how,  and  how  much 
programmer  activity  is  expected?  If  there  is  a need 
that  is  large,  then  the  problem  of  how  to  accomplish 
this  is  very  important.  Should  the  function  be 
combined  with  the  engineering  tasks? 


If  the  need  is  small,  how  will  it  be  accomplished? 
Will  the  regular  console  fxmctions  handle  this  load? 
Will  the  computer  console  be  used?  Is  there  a 
computer  terminal?  Will  the  computer  need  to  be 
shut  down  for  changes  (foreground  only  vs.  fore- 
ground-background  ) ? 
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- Maintenance 

Are  there  provisions  in  your  design  to  accomplish 
control  system  and  computer  maintenance?  What 
effect  does  preventative  maintenance  (PM)  have  on 
the  system?  Can  PM  be  performed  on  line?  Is  PM 
necessary?  If  not,  then  when  repairs  are  made,  how 
do  the  diagnostics  get  into  the  system?  What  about 
storage  media,  ease  of  use,  etc. 

- Training 

What  effect  will  the  training  of  personnel  have  upon 
the  console  design?  Wl:at  provisions  for  training 
are  to  be  made?  Is  the  console  simplistic  enough? 
Has  Human  Factors  Engineering  (HFE)  been  used  pro- 
perly? Can  a regular  operator  be  trained  easily? 
Does  the  system  make  the  operator  feel  he  has  a new 
tool  or  an  operational  aid?  Is  the  communication 
between  operator  and  the  processor  adequately  des- 
cribed and  instructions  easily  understood?  Are  the 
operators  old  or  new  to  this  task?  Has  the  training 
taken  into  account  that  operators  generally  resist 
change? 

1.2.2  Modes  of  Operation 

What  kinds  of  operational  modes  are  to  be  performed. 

This,  again,  impacts  on  the  console  design. 

- Normal  Operation 

Can  you  define  how  the  system  is  to  run  in  the 
normal  operating  mode?  Does  this  include  startup 
and  shutdown? 

What  does  the  "normal"  type  operation  mean? 


-Operate  in  supervisor  fashion  with  setpoint 
changing  (closed  loop  supervisory). 

-Operate  in  DDC  mode  with  appropriate  back- 
ups (closed  loop). 

-Opei'ate  in  monitor-type  mode  with  instruc- 
tio!i3  to  operators  (open  loop  control). 

If  startup  is  to  be  performed  - how  will  this 
be  accomplished?  Supervisory  and/or  open  loop 
directed? 


Shutdown  - is  this  a normal  function  or  emergency" 
How  will  it  be  accomplished?  Supervisory  and/or 
open  loop  directed? 
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- Background  Mode 

Is  the  system,  during  normal  operation,  capable 
of  performing  tasks  other  than  control? 

(examples)  -Compiling  programs  for  real  time  control 
use. 

-Compiling  eind  executing  scientific  type 
programs  (Fortran). 

-Performing  laboratory  analyses  or  lab  cal- 
culations. 

-Simulation  of  the  plant  in  a faster-than- 
actual-time  frame. 

-Analysis  and  debugging  of  operating 
programs  and  computer  operating  system 
during  operation. 

- Emergency  Mode 

What  is  to  be  performed  during  emergencies?  Tasks 
should  be  outlined  as  well  as  how  they  will  be 
accomplished.  Make  a task  list  for  control  actions. 

Does  this  include  emergency  maintenance  of  system? 

- Maintenance 

Have  provisions  been  made  to  accomplish  as  much 
maintenance  as  possible  while  on-line  (effecting 
production)?  See  "security  etnd  safety"  for  plant 
operation  while  off-line. 

- Operational  Goals 

In  any  of  the  above  categories  does  the  operator 
have  the  requirement  to  set  the  operational  goals, 
or  is  this  function  restricted?  If  the  operator 
does  set  the  goals,  does  he  also  have  the  option  to 
commit  available  resources  to  accomplish  this  task 
(i.e.  can  he  change  the  plant  from  one  level  to 
another  and  appropriate  the  feedstock,  utilities, 
equipment  and  manpower  required)?  If  the  operator 
is  restricted,  does  he  have  ready  access  to  the 
people  who  can  set  goals?  Especially  during  emer- 
gencies? 

- Off-Line  Operation 

Is  there  to  be  a requirement  for  the  computer  to 
perform  off-line  (while  the  production  unit  is 
down)?  If  background  tasking  is  not  available,  then 
off-line  operation  could  include  recompiling  or 
assembling  changes  to  be  made  in  the  system.  If  the 
process  unit  operates  for  short  periods  of  time, 
with  time  available  between  production  runs,  some 
sort  of  EDP  functions  could  be  accomplished  during 
these  short  breaks. 
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, 1.2.3  Security  and  Safety 

Is  the  system  protected  from  casual  or  accidental-type  of 
button  pushing?  Does  the  system  have  a watchdog  timer  or 
similar  protection  against  program- looping  or  getting 
lost?  Does  the  watchdog  timer  protect  against  automatic 
restart  as  in  a power  failure  when  you  don't  want  it  to 
I restart  automatically  (maybe  because  its  been  down  too 

f long)? 

^ Are  the  system-programs  protected  (either  by  software  or 

[ hardware)  while  in  operation?  Is  the  system  protected 

[ with  backup  software  which  is  stored  in  a safe  place?  Is 

j,  the  hardware  special  or  can  it  be  replaced  easily  in  case 

of  an  accident?  Goraetimes  it's  worth  going  with  a stan- 
I dard  model  to  lessen  the  accidental-loss  risk. 

Can  the  necessary  safety  or  recovery  actions  be  performed 
from  the  console  with  the  required  speed? 

Is  the  control  room  designed  to  minimize  traffic  and  let 
1 only  the  authorized  personnel  access  to  the  computer?  Is 

there  a visitor's  viewing  gallery  "requirement"? 

Are  there  to  be  keylocks  on  the  console  or  other  types  of 
security  (such  as  code  names)  for  separation  of  duties? 

! How  are  these  "priviledge  codes"  to  be  controlled  and 

monitored? 

Are  there  security  overides  when  necessary?  An  example 
might  be  during  startup  when  normal  or  built-in  con- 
straints must  be  overridden. 

1.2.k  Management  Objectives  and  Restrictions 

Here  the  definitions  from  management  must  be  reviewed  and 
their  impact  on  the  console  evaluated,  not  only  the 
number  of  persons  to  be  involved  in  the  control  center 
operation,  but  any  other  requirements  by  management  or 
the  government.  There  are  other  restrictions  that  may  be 
imposed  - Is  the  job  to  be  performed  standing-up  or 
■ sitting-down?  Management  may  decide  the  console  should 

be  a certain  length,  height,  color  or  configuration.  Are 
there  other  jobs  or  tasks  to  be  performed  besides  the 
main  task  performed  at  the  console  (in  other  words,  off- 
line duties)? 

Here  also  the  definition  of  how  the  plant  is  to  be  run  is 
determined.  It  may  be  general  (i.e.  certain  cases  run  in 
production-limited  mode,  otherwise  run  in  raw-material- 
: efficiency  mode)  or  it  may  be  very  specific  (i.e.  main- 

tain certain  conditions  regardless  of  productivity  demands 
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or  raw  materials  being  used).  Other  examples  might  be: 

If  a batch  plant  operation,  the  product  qviality  between 
batches  must  remain  within  certain  limits.  If  a con- 
tinuous plant,  the  product  may  vary  depending  on  the 
demand  or  customer  (i.e.  crude-distillation  tower  opera- 
tion to  give  more  gasoline  or  more  heating  oils).  Cer- 
tain management  restrictions  also  imply  a special  type  of 
record  be  kept.  This  could  impact  the  console  require- 
ments, and  certainly  impacts  on  operations  personnel 
requirements. 

1.2.5  Government 

Government  also  impacts  the  console  objectives.  This  may 
be  very  dependent  on  the  industry.  OSHA  or  EPA  may 
require  certain  objectives  be  met  and  records  kept  for  a 
number  of  years.  Legal  requirements  could  also  be  a 
cause  for  some  console  considerations.  There  are  very 
specific  requirements  placed  upon  control  rooms  for 
Nuclear  Power  Plauits  by  the  Nuclear  Regulatory  Agency, 
for  example. 

1.2.6  Pacing 

Man  or  machine  - which  paces  the  other?  Here  again,  this 
appears  to  be  an  industry  dependent  variable,  but  this 
shoxild  not  be  over-looked.  (For  more  on  pacing,  see 
3.2.9  re  "Psycological  Fit") 

Do  not  forget  that  for  certain  times  the  nature  of  pacing 
may  switch.  As  an  example,  during  startup  and  shutdown 
the  man  may  pace  the  machine,  but  during  normal  produc- 
tion the  machine  may  pace  the  man.  The  exact  reverse 
situation  can  also  occur!  Other  examples  - during  batch 
operation  the  machine  may  pace  the  man  until  an  unusual 
occurence  - then  control  will  defer  to  the  man.  In  a 
continuous- furnace  control  operation  the  machine  will 
pace  the  man  m.  Ml  restrictions  of  some  variables  make 
the  automatic  solution  unattainable.  Then  the  alarm 
alerts  for  the  man  to  take  over,  and  the  man  would  then 
be  pacing  the  machine. 
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2.0  Control  Center  Requirements 


In  the  previous  section  we  examined  how  the  Man/Machine  Interface 
might  be  influenced  by  the  higher  level  requirements  of  overall 
process  and  system  objectives.  Now  we  picture  the  control  center 
itself  and  identify  factors  which  are  relevant  to  it  directly. 


2.1  Management  Requirements 

This  section  will  enumerate  some  of  the  types  of  company 
policies,  industry  standards,  licensing  regulations,  major 
equipment  contractoi-' s requirements , and  management  goals  and 
decisions  that  may  lead  to  restrictions  and  requirements  on 
the  MMIF  itself.  (The  guideline  user  must  keep  in  mind  that 
the  following  examples  were  chosen  only  as  a random  collec- 
tion of  typical  requirements.  As  these  examples  jog  the 
user's  mind,  he  should  write  down  his  corresponding  or  related 
actual  requirements.) 


-1  MMIF  Hardwau’e  Resti-ictions 


-Specifications 

What  are  the  hardware  restrictions  that  affect  the 

design  of  the  ND-lIF? 

Some  examples  of  such  restrictions  MIGHT  be; 

a)  The  console  will  be  painted  company  colors; 

b)  The  console  will  consist  of  equipment  made  by 
union  companies  in  the  U.S.A.; 

c)  The  t-OilF  will  withstand  the  factory  environ- 
ment ; 

d)  Provide  for  the  following  planned  future  im- 
provements   ; 

e)  Provide  for  the  follow'ing  operational  modes  on 

a single  console:  normal,  emergency,  shutdown, 

startup,  maintenance; 

f)  Provide  for  in-house  maintenance  instead  of  an 
outside  vendor; 

g)  Make  the  MMIF  a showplace  for  public  rela- 
tions and  tours; 

h)  Provide  for  computer  system  backup; 

i)  Provide  for  man\ial  overides; 
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i)  Make  this  t-lMIF  hardware  and  software  compatible 
with  our  other  interfaces; 

k)  Use  commercially  available  equipment  instead  of 
in-house  design  and  fabrication; 

l)  This  equipment  must  last  the  life  of  the  pro- 
ject, which  is  "X"  years; 

m)  There  must  be  a graphic  representation  of  the 
process  on  or  near  the  MMIF; 

n)  The  t'iMIF  must  have  less  than  0.5^  downtime; 

o)  Keep  the  overall  cost  less  than  "X"  dollars. 

- Legal 

What  are  the  legal  requirements  that  apply  to  the 

MMIF?  Some  examples  MIGHT  be: 

a)  Safety,  such  as  no  sharp  edges,  and  providing 
hi-voltage  or  other  warning  signs  where  appro- 
priate; 

b)  Health,  such  as  no  toxic  fumes  or  high  noise 
levels ; 

c)  May  have  to  provide  for  on-the-Job  training; 

d)  Licensing  or  leasing  may  require  nameplates  or 
other  items  of  inventory  and  packaging  control. 

e)  Production  reports  or  other  logs  may  be  a legal 
necessity. 

-2  Operator  Restrictions 

- Selection 


What  are  the  operator  restrictions  as  they  relate  to 
the  type  of  operator  that  will  use  the  MMIF?  Some 
examples  of  operator  restrictions  MIGHT  be: 


a) 

This 

operator 

must 

be 

b) 

This 

operator 

will 

be 

c) 

This 

operator 

will 

be 

d) 

This 

operator 

will 

be 

e) 

This 

position 

will 

be 

I 


I 

1 
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f)  This  position  will  be  used  as  a training  too] 
for  personnel  being  promoted  from  a lower 
position  to  a higher  position; 

g)  This  operator  must  pass  certain  tests; 

h)  This  operator  must  pass  a security  check. 

i)  This  operator  must  posses  normal  (color  vision, 
hearing,  and  manual  dexterity. 


- Responsibility 

What  are  the  management  restrictions  that  apply  to 
the  Operator's  Responsibilities  and  authority? 


Some  examples  of  these  restrictions  lilGHT  be; 

a)  The  number  of  operators  at  the  console; 

b)  The  amount  of  relief  time  for  the  operator; 

c)  Secondary  duties  that  are  required,  such  as 
maintenance  or  clean-up; 

d)  How  much  authority  the  operator  has,  how  much 
of  the  available  resoui’ces  the  operator  is 
permitted  to  commit,  or  use; 

e)  How  much  responsibility  the  operator  has; 

f)  How  the  operator's  performance  is  to  be  measured. 

- Legal 


What  are  the  legal  requirements  that  apply  to  the 
operator?  Some  examples  MIGHT  be: 

a)  Operator  may  be  young  or  old; 

b)  Operator  may  be  male  or  female; 

c)  Operator  may  I’equire  relief  time  or  scheduled 
break.s . 


- Monitoring  and  Pacing 

Does  management  require  the  machine  to  monitor  the 
operator,  or  the  operator  to  monitor  the  machine,  or 
somewhere  in  between?  Is  the  machine  to  pace  the 
operator,  or  is  the  operator  to  pace  the  machine? 
Some  examples  of  the  vai’ious  modes  of  operation  are 
as  follows: 


4 


i 

i 


I 


I 


t 


J 


-17- 


2.1.2 


a)  The  machine  makes  the  decision  and  completes 
the  action,  then  notifies  the  operator; 

b)  The  machine  makes  the  decision,  notifies  the 
operator,  then  completes  the  action  - this 
allows  the  operator  to  manually  override  the 
action; 

c)  The  machine  suggests  an  action,  then  waits  for 

an  operator  reply  which  could  be:  l)  no  reply 

within  a time  period  means  O.K. , 2)  no  reply 
means  not  O.K.  and  machine  trys  something  else, 
or  waits. 

d)  The  machine  alerts  the  operator  to  a problem 
and  waits  for  a decision. 

2.1.3  Records  and  Logs 

Hisorical  records  and  logs  as  required  by  management. 

Some  examples  of  these  are: 

a)  Production  summaries  by  shift,  day,  week,  month, 
etc. ; 

b)  Shift  or  crew  comparisons; 

c)  Equipment  downtime  and  reasons; 

d)  Trending  Charts; 

e)  Set  point  changes  log; 

f)  Plotting  capabilities; 

g)  MMIF  downtime  and  repair  log; 

h)  Alarm  logs; 

i)  Records  of  operational  variations,  equipment  by- 
passing. 

j)  Operator's  Communications  records  (like  in-flight 
recorders  for  example) 

k)  "Instant  Playback"  capability  as  used  to  "trace" 
sequence  of  events  that  caused  a failure  or  acci- 
dent. (casualty  information) 


-J3- 


2.2 


E 


» • 

J 

r 

L > 


Lt. 


2.2  Environmental  Factors 

Environmental  factors  may  enhance  or  degrade  the  performance 
of  the  Man/Machine  Interface.  Use  of  environmental  factors  to 
enhance  performance  is  part  of  the  designer's  objective.  This 
section  is  divided  into  three  areas  of  focus:  rr-an-centered , 

machine-centered,  and  physical  layout. 

Man-centered  environmental  factors  are  those  factors  vhich 
effect  the  operators  themselves  as  the  designer  looks  at  the 
interface,  ie,  those  environmental  factors  which  effect  or 
restrict  the  human  factors  engineering  design. 

l^lachine-centered  environmental  factors  are  those  factors 
within  the  immediate  area  of  the  interface  which  affect  the 
hardware  design  and  implementation. 

Note:  The  above  two  catagories  of  environmental  conditions 

or  factors  are  not  necessarily  the  satoe.  Each  does 
not  include  all  of  the  same  elements.  A good  example 
of  this  is  noise.  Noisy  environments  will  often 
degrade  man's  performance  but  will  not  likely  effect 
the  components  of  the  control  console  in  the  same 
way,  if  at  all. 

Physical  layout  requirements  form  a separate  catagory  of 
environment.  It  includes  both  man  and  machine  factors,  often 
simultaneously.  Physical  layout  may  often  be  used  to  compen- 
sate in  part  for  an  otherwise  poor  environment  around  the  MMIF 

-1  Man-Centered  Environmental  Factors 

As  the  designer  emomerates  and  evaluates  the  environ- 
mental factors  effecting  man  he  should  keep  in  mind  that 
man  perceives  his  environment  entirely  through  his  five 
senses,  but  that  his  reaction  to  these  input  signals  can 
be  quite  complex.  Sociological  factors,  for  example,  are 
quite  complex  reactions  to  sensory  inputs.  The  man-model 
referred  to  later  in  this  outline  can  be  useful  in  evalu- 
ating the  importance  of  the  various  environmental  factors 
as  they  effect  man's  fihysical  ability,  endurance,  mental 
ability,  fatigue,  etc..  The  environmental  factors  listed 
below  have  been  divided  into  categories  according  to 
their  usual  effects  on  man.  The  categories  are  somewhat 
arbitrary  and  overlaping  but  serve  the  purnose  of  high- 
lighting important  effects. 

- Effects  on  Sensory  Precept ions. 

a.  Temperature/humidlty/ventilation.  The  range 

and  variations  of  these  factors  effects,  among 
other  things,  man's  comfort  and  endurance. 
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b.  Sound.  This  factor  can  have  both  positive  a.nd 
negative  effects.  Such  factors  as  frequency, 
intensity,  duration,  variation,  composition, 
etc.  are  important. 

c.  Vibration.  This  factor  is  similar  to  sound  but 
may  have  added  effects  on  sense  of  feeling. 
Vibration  rarely  enhances  environment  for  MMIF. 

d.  Light.  Factors  such  as  color,  shade  intensity, 
duration,  and  variation  should  be  considered. 
Illumination  and  glare  can  effect  ability  to 
read  for  example.  Poor  choices  of  color  can  be 
emotionally  irritating  under  some  conditions. 
Properly  used  lighting  effects  can  significantly 
enhance  the  MMIF  environment. 

e.  Texture  and  geometry.  These  factors  may  often 
be  used  to  enhance  environment  and  the  accuracy 
of  man's  output.  Examples  of  this  factor  used 
to  advantage  are  the  use  of  different  sizes  and 
colors  of  panels  for  different  functional 
partitions  of  I^IF. 

f.  Dust  and  other  nontoxic  contamination.  These 
factors  may  reduce  comfort  and  endurance. 

Effects  on  Mental  and  Psychological  Behavior 

a.  Data  rate  input  to  man.  Man  may  not  be  able  to 
use  information  if  he  receives  too  much  too 
rapidly. 

b.  Variety  of  input  form  and  type.  Data  of  simi- 
lar type  should  be  presented  to  man  in  the  same 
way.  Variety  of  method  of  presentation  may  be 
used  to  advantage  as,  for  example,  critical 
variables  presented  continuously  on  dedicated 
indicators . 

c.  Consistancy  and  organization.  These  are  really 
human  factors  engineering  subjects.  However, 
some  inconsistancies  and  disorganization  may  be 
dictated  by  plant  or  control  room  restrictions 
in  which  case  they  become  environmental  disad- 
vantages . 

d.  Effects  on  "arousal  level".  See  human  factors 
section  and  the  "man-model".  This  is  an  impor- 
tant effect  but  it  must  be  used  carefully. 

Such  things  as  alarm  bells  or  flashing  lights 
are  often  used.  Man's  response  often  is  a shift 
of  "arousal  level"  and  can  result  in  erroneous 
action.  For  example,  if  there  are  too  many 
alarms,  an  operator  will  learn  to  ignore  them 
and  may  miss  seeing  an  important  one. 
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e.  Fatigue  and  stress.  .4re  there  factors  which 
generate  stress  and  fatigue,  which  can  degrade 
man's  performance? 

f.  Comfort  factors.  Are  there  comfort  factors  or 
can  some  be  added  which  may  compensate  fc>r 
stress?  Can  the  operator  stand  up,  sit  down  or 
move  about?  Is  the  physical  working  space 
large  enough,  and  is  the  room  environment 
adequate? 

- Factors  With  Physical  Limitations 

a.  Amount  and  rate  of  output  required  of  man.  Can 
the  operator  do  the  assigned  job  at  the  rate 
pre-3cribed  and  yet  maintain  the  necessary 
reserve  energy  for  possible  contingency  situa- 
tions? 

b.  Toxicity/health  hazards. 

c.  Nuclear  radiation. 

2.2.2  Machine-Centered  Environmental  Factors 

- Temperature  and  humidity  range  and  level  ( i the  ira- 
chine's  requirements  exceed  the  man's  requirements). 

- Vibration,  seismic  requirements 

- Electromagnetic  radiation.  Ultra-violet,  X-ray,  radio- 
frequency,  etc.  (a  two-way  radio  near  a computer  t.*an 
disrupt  its  operation. ) 

- Electrical  noise  (Any  sporadic  electrical  load  on  trie 
same  supply  circuit  as  a computer  will  lixely  disrupt  its 
operation. i 

- Dust  and  other  contaminaticri  (in  refineries  and  ciiemi- 
cal  plants,  H G usually  effects  electrotiics  components  at 
levels  lower  than  man's  tolerance). 

- Nuclear  radiation 

- Variety  of  input  forms  from  plant  or  man. 

2.2.3  Physical  Layout. 

- I'redetermined  factors  from  overall  oper.ation  require- 
ments. 

- Visual  observat.ion  of  the  process.  Required  or  not? 


- Explosion  proofing. 
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- Safety 


- Consistency.  If  there  are  several  operators  or  oper- 
ating stations,  can  similar  jobs  be  acne  in  similar  ways 
with  similar  equipment? 

- Other  working  conditions,  kiring  on  floor,  obstacles, 
conveniences,  etc. 
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3 . 0 Man/Machine  Interface  Design  Factors 

In  the  previous  sections  of  the  guidelines,  emphasis  has  been  on 
establishing  the  performance  goals  that  the  Man/Machine  Interface 
should  support  and  under  what  contraints  of  policy,  manpower, 
control  strategy,  and  physical  environment  the  Personnel  Subsystem 
of  Fig.  i.l  must  exist. 

We  are  now  ready  to  proceed  to  the  next  step  in  interface  design. 

First  the  restrictions  and  requirements  generated  in  Guideline 
Sections  1.0  and  2.0  above  should  be  reviewed  and  organized.  Then 
with  human  factors  engineering  and  hardware  characteristics  con- 
siderations, the  actual  interface  can  be  defined. 

3.1  Organization  of  the  Design  Approach 

A thorough  preparation  for  design  requires  the  organization  of 
a considerable  number  of  factors.  Some  appreciation  of  the 
problem  may  be  grasped  by  a reference  to  Figure  1.0,  which 
showed  a comprehensive  flow  chart  for  the  design  process. 

We  are  now  on  the  threshold  of  Human  Factors  Engineering  and 
Control  System  Engineering.  (Again,  refer  to  Figure  1.0) 

- Questions  that  should  have  been  asked  and  answered  by  now[ 

In  order  to  fully  utilize  the  following  information  in 
this  section  of  the  Guideline,  you  must  have  a well- 
defined  purpose  in  mind.  If  you  have  answered  all  of  the 
following  questions,  you  will  have  a restricted  set  of 
requirements  for  the  MMIF.  If  you  have  not  considered 
the  following  questions,  but  wish  to  continue  thru  this 
section,  you  are  assummed  to  have  adopted  some  precon- 
ceived notion  about  MMIF  design,  and  the  Guideline  will 
be  of  much  less  use  to  you. 

1.  Will  you  utilize  existing  manpower  or  select/train 
according  to  design  requirements? 

2.  What  is  the  prime,  motivation  for  involving  a manned 
control  console? a \ Typical  sections  of  HFE  needed) 

- Research  or  pilot  plant  (all) 

- Unpredictable  process  ( feedback  8e  trending  & auto 

alarming  heirarchy) 

- Incomplete  automation  (feedback) 

- Poor  reliability  in  hardware /software  (feedback) 

- Lack  of  confidence  in  automation  ("consistent  MMIF" 

& feedback) 

- Traditional  (stereotyping) 

- Safety  requirements  (accuracy,  error  recovery,  trans- 
parency) 

- Maximize  performance  of  system  (all) 
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3.  What  is  the  available  manpower  pool? 

- Open  market 

- Regional  market  (selection  8e  training) 

- Internal  recycling 

- Contractual 

U.  What  are  the  physiological  restrictions  for  operators? 

- Need  all  physical  abilities 

- Need  only  specified  abilities 

(can  accommodate  Handicapped) 

5.  What  are  the  psychological  restrictions  for  operators? 

- Personality  types 

- aggressive,  dynamic,  imaginative,  non-conformist 

- conservative,  obedient,  conformist 

- Intellectual  types 

- semi-literate 

- decision  makers,  thinkers,  innovators 

- consistent  and  reliable 

- meticulous  and  logical 

- Social  types  (personality) 

- gregarious 

- loners 

6.  What  work  patterns  will  be  required? 

- Man  pace  machine  or  machine  pace  man 

- Standard  daytime  hours/work  schedule 

- Shift  hours,  regular  schedule 

- Highly  intermittent,  on  demand 

7.  What  type  of  manpower  is  involved  in  use  of  console? 

- Control  engineer 

- Programmer 

- Maintenance 

- Shift  or  routine  operators 

- Clerical  workers 

- Managers 

- Supervisors 

- Design  analysts 

- Casuals  (part-time) 

8.  What  are  the  rules/requirements  of  access  to  console? 

- Restricted  by  authority 
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9.  Are  back-up  personnel  needed  for  any  types? 

- Emergency  or  routine  occasions 

- Redundant /dedicated  or  temporary  stand-in 

10.  >/hat  are  motivations  of  operating  personnel? 

- Monetary  (hourly,  salary,  or  profit  sharing) 

- Self-driven  curiosity  (researcher,  desigiier) 

- To  meet  minimum  specified  performance  requirements 
according  to  some  historical  precedent  (union) 

11.  Are  job  enrichment /enhancement  methods  to  be  utilised? 

- In'iustrial  relations’ 

- Industrial  psychology 

12.  tTiat  is  the  involvement  of  operating  personnel? 

- Involved  in  operations,  as  scheduJ cd  by  others 

- Involved  in  design  iraplementanion 

- Involved  in  goal-setting 

- Involved  in  decision  making,  arbitration 

- Involved  in  control  system  upgrading 

- Involved  only  in  event  of  breaKdo\/ns  cc  erergencv 

13.  'Who  will  be  allowed  to  recommend /request  changes  r.r 
improvements? 

- Operators  - maintenance  technicians,  engineers  - 
supervisor  - management 

1)4.  Are  the  prime  objective/goals  defined  and  documented'; 

- Restricted  access  information 

- Openly  published  infoimial ion 

- Abstracted,  or  detailed  information 

15-  Are  the  acceptable  metliods  oi'  achieving  the  pr'm- 
objectives/goals  defined  and  docuraente i'.' 

- As  above  plus  prioriti es/preferences  of  nethods 

16.  Are  tne  constrni  n1  s/rerd  .’•ictlons  for  tlu>  ach  i (>verien< 
of  objective/goals; 

- Temporary  or  pemianent? 

- Legal  or  otiu'cal? 

- Economic  or  technological? 

17.  'What  personnel -select ion  met’uods  wi  1 1 bo  employt  i? 

- Internal  upgradiugA-ecycli  tig 

- Screening  and  apt  itude/sk  i U test;s 

- Competition  or  senority-rul c 
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18.  What  personnel-training  methods  will  he  used? 

- On-the-job  training  (timeshared  or  rotation) 

- Buddy-system  (with  supervisor  or  senior  operator) 

- Published  training  manuals/aids/siraulators 

- On-line  or  off-line  training 

- Automatic  upgrading  by  senority  or  ability 

- Training  by  simulation  machines  or  devices 

19.  Is  there  a program  for  turnover  replacement? 

- Scheduled  or  unscheduled  (by  time,  by  performance, 

or  by  potential  abilities) 

20.  How  is  the  performance  of  personnel  evaluated? 

- Measurable  performance  criteria 

- Supervisor  rated 

- Continuous  or  periodic  (what  period/cycle?) 

21.  What  is  the  organizational  structure  of  the  opera- 
ting personnel? 

- Team  or  task  force  (responsible  to  who?) 

- Departmental 

22.  Wliat  are  the  operations-personnel  reserve  resources 
during  crises  or  emergencies? 

- Back-up  force 

- Re-assigned  stand-ins 

23.  Will  operator's  successful  operations  algorithms  be 
re-invested  into  automated  control? 

- As  they  occur 

- With  periodic  re-design  evaluations 

- Or  used  instead  to  upgrade  operator's  training  and 
operation  requirements,  and  procedure  manuals? 

2k.  Is  the  facility  or  process  a new  one  or  a recycled 
(updated)  one? 

- Do  precedents  of  performance  exist?  (for  machine, 
for  operators) 

- Do  stereotypes  exist?  (for  machine,  for  operators) 

25.  How  are  conflicts  resolved  for  operational  methods? 

- By  on-line  performance  requirements 

- By  off-line  management  decisions  (policies  or 
laws) 

- By  decision  maker (s) 


I 


I 
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26.  Is  the  mode  of  operation  based  on  desire  to  achieve 
previously  unrealizable  goal,  or  to  maintain  past 
history  of  success  without  failure? 

The  answers  to  these  questions  will  establish  the  character  of 
the  personnel  requirements  which  the  NPilF  design  must  satisfy! 

Next,  you  should  be  able  to  answer: 

for  DISPLAYS; 

What  is  being  displayed?  (Information  item,  vali- 
dity) 

Why  is  it  being  displayed?  (Usage,  causa] ity) 

How  is  it  being  displayed?  1 Physical  form  and 
location) 

When  is  it  being  displayed?  (Control  of  the  dispi ay- 
device  timing) 

Where  does  it  come  from?  (From  source  directly  or 
calculated) 

But  ....  WHAT  are  you  really  telling  the  Operator? 
for  CONTROLS: 

Wl^at  is  being  controlled?  (Device  directly  or 
calculated  parameter) 

Why  is  it  being  controlled?  (Usage  ob,)ocziv", 
algoritiun) 

How  is  it  being  controlled?  (Physical  i'oi-m, 
strategy) 

Wtien  is  it  being  controlled?  (Control  of  : he 
control  device  timing) 

Where  does  the  control  signal  go?  (Destitial  ior, ) 
But  ....  what  are  you  asking  tlie  Operator  to  ACCOMPLISH? 


SUimRY : 


If  each  of  the 
cribed  early  in  the 
good  chance  to  do  a 
powerful  definition 


above  checklist  items  can  be  confronted  and  des- 
systera's  design,  we  feel  that  the  designer  has  a 
top-down  design.  Tlie  results  will  be  early  and 
for : 


Data  base  description 
Signal  and  activator  lists 
Statements  of  objectives 

Basis  for  project  task  breakdowns  (allocations 
of  effort) 

Early  identification  of  R & D requirements 
Basis  for  strategy  developments 
Potential  problem  areas. 

Algorithms  of  display  and  control 
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3.2  Human  Factors  Engineering 

When  it  comes  to  the  actual  design  specification,  the 
characteristics  of  the  human  operator  must  be  matched  to 
the  characteristics  of  available  hardware,  to  meet  system 
objectives.  To  achieve  this,  an  understanding  of  the 
physical  and  mental  performance  limits  of  the  operator 
should  be  taken  into  account. 

This  involves  the  relatively  young  field  of  scientific 
study  called  Human  Factors  Engineering  (HFE).  It  is  the 
scientific  approach  to  the  optimization  of  human  perfor 
mance  for  performing  physical  and  mental  tasks.  It  is 
beyond  the  scope  of  these  Guidelines  to  cover  the  exten- 
sive field  of  information  that  has  accumulated  on  this 
subject.  A vast  literature  exists.  A very  brief 
bibliography  is  included  in  the  guideline  which  should 
provide  the  reader  a useful  introduction  to  Human  Factors 
Engineering  (HFE). 

In  brief,  our  interest  here  is  to  use  HFE  to  attempt  to 
provide  quantitative  and  qualitative  measvures  of  man's 
sensory  responses  to  stimuli  as  well  as  establishing  his 
capacity  for  mental  data-processing  tasks.  A popular 
approach  to  the  study  of  the  operator  is  to  develop  models. 

As  an  example.  Fig.  (3.2)  depicts  one  such  concept.  No 
discussion  of  this  model  is  attempted  here.  It  is  introduced 
merely  to  indicate  the  extent  to  which  HFE  attempts  to  study 
the  behaviour  of  the  human  operator.  The  references  must  be 
consulted  for  a further  \inderstanding. 

It  woxild  appear  that  the  human  data  processing  capability 
becomes  the  significant  consideration  in  the  design  of  the 
t^lMIF.  It  is  not  so  much  the  physical  aspects  of  the  hardware 
that  are  of  prime  importance,  but  rather  the  encoding,  organi- 
zation and  presentation  format  of  data  made  available  for 
decision-making  purposes.  The  hximan  must  be  able  to  absorb 
them,  and  make  decisions,  and  take  appropriate  actions  effi- 
ciently and  accurately. 

3.2.1  Decision  Making 

A checklist  of  questions  that  bear  on  decision  making 
are: 

1.  How  is  it  obvious  that  a decision  must  be 
made?  - arousal  and  attention  (alarming)  - 

2.  What  forms  of  perception  are  utilized  for 
arousal? 


3.  What  forms  of  action  are  used  for  resultant 
output? 


DISCklHINATlON 
THRESHOLD  AND  GAIN 


INTERNAL  CLOCK 

•CIRCADIAN 

•STRESS 

•ROUTINE 


‘REFRESH 

RATE 


TASK 

SCHEDULER 

•MONITOR 

•PRIORITIES 


SO 


DYIAMIC 

MOTIVATION 

KOOELING 

•PRECEDENCE 

SENSORY 
INFORMATION 
INPUTS 

I 


HUMAN 

SENSORY 

INPUTS 
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SHORT-TERM 

MEMORY 

•BUFFER 

•PERCEPTION 


I 


INFORMATION 

PROCESSING 


?>■ 


COGNITION 
■ENCODING/OECOOING 
BY:  -TIME  ASSOCIATION 
•SPACIAL  ASSOCIATION 
•OPERATION  ASSOCIATION 
•MODEL 


"'DATA' 


LONG-TERM 

MEMORY 

GENERAL 

ALGORITHMS 

TRIVIA 

HOOF 1 S 

DECISION 

MAKING 

•SYNTHESIS 

•ANALYSIS 

•PREDICTING 


I 


HUMAN 

OUTPUT 

•MOTOR  RESPONSE 
•VOCAL 


FIGURE  3.2 

GENERAL  INTERNAL  OPERATOR  MODEL 
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4.  Wiiat  are  timing  requirements  on  decision-making 
process? 

5.  What  are  accuracy  requirements? 

6.  What  is  the  information  source? 

external  process,  actual  data,  real-time 
process  model,  simulated  data,  speeded-up 
model,  predictive  data,  mental  model 

T.  Are  all  relevant  goals  and  objectives  definable? 

8.  Are  all  allowable  methods  of  arbitration/compromising 
outlined? 

speed  vs.  accuracy 
safety  vs.  economy 
efficiency  vs.  personal  comfort 

9.  What  are  forms  of  input  data? 

hierarchical,  structured,  filtered 
by  demand,  raw,  noisy 
historical  records/trending 
sampled  data  (time  base) 

hysteresis,  dead  band  limiting,  and  "wrap- 
around" effects 

10.  Are  the  real-time  probabilities  of  values  and 
excursions  for  input  variables  \inderstood? 

11.  Are  a.'.l  probable  errors  accounted  for? 

- substitution,  reversal,  ommission . . . . 

12.  Does  nature  of  decision  involve  qualitative  or 
quantitative  measures  or  data? 

differential  (with  or  without  ready  reference?) 
absolute  (on  what  scale?) 

13.  Are  records  available  of  previous/similar  deci- 
sions and  consequences? 

expectations  (consistent  or  inconsistent 
process  behavior) 

14.  Is  feedback  provided  for  consequences  of  present 
decision /act ion? 

- performance  monitor  (real-time,  delayed,  simu- 
lated) 

15.  Are  operator  conversions  required  between  types 
of  data  as  provided,  and  resultant  control  output 
required? 


I 

i 


l6.  When  is  it  obvious  that  a higher  level  of  decision 
maker  is  needed? 
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IT.  Is  the  reliability  or  validity  of  the  data 

(measurement  devices)  known  or  can  it  be  checked? 
self-diagnostic  instruments 
calibrated  checks 
status  or  validation  flags 

18.  Is  it  obvious  when  input  information  or  output 
controls  are  faulty? 

behavior  of  status  or  validation  flags 

19.  Are  operator's  display/controls  compatible  with 
the  accuracy,  speed,  economy,  and  flexibility 
desired? 

economy;  slow,  serial,  multipurpose  devices 
accuracy:  dedicated  devices 

speed:  paralleled-access  devices 

flexibility;  multi-assignment  devices 

20.  Is  quantitative  information  available  in  quali- 
tative form  when  higher  speed  decisions  are 
required? 

21.  Is  the  operational  status  of  all  data  acquisi- 
tion and  control  devices  known?  If  not,  can 
they  be  interrogated? 

verification  of  status  or  validation  flags 

3.2.2  Motivation 

Motivation  is  a part  of  man’s  personality,  but  we 
are  considering  it  seperately  because  of  its  impor- 
tance in  relation  to  his  behavior  as  an  operator. 

Motivation  can  be  considered  to  be  made  up  of  the 
following  traits: 

Volition,  curiosity,  interest,  initiative, 
imagination,  knowledge,  commitment,  perse- 
verance, drive,  enthusi.asm. 

(Note:  Human  volition  is  what  makes  people  create 

goals  for  themselves,  and  is  the  primary  difference 
between  biological  systems  and  mechanical  systems. 

Duty  and  obligation  are  forms  of  commitments. 

Curiosity  and  knowledge  are  prerequisite  to  the 
traits  that  follow  in  the  list.) 

3.2.3  Arousal 

Arousal  is  the  awakening  or  promting  concept  which 
attracts  a man's  attention  so  that  he  may  begin 
processing  information.  In  the  case  of  perception. 


!■ 


eacn  of  the  various  senses  has  their  own  arousai 
threshold.  In  the  case  of  man'.s  internal  informa- 
tion-processing, arousal  provides  cures  which  prompt 
fiirtner  actions.  The  time  between  the  first  signal 
and  the  arousal  is  the  arousal -lag-t ime . 

We  are  concerned  here  with  arousal  as  related  to  the 
external  signals  or  cues  which  prompt  an  operator. 
These  cues  are  called  alarms  if  they  are  used  for 
purposes  of  re-directing  the  operator's  attention. 

In  that  event,  they  are  really  priority  indications. 

It  will  be  useful  to  rank  the  level  of  arousals 
desired  into  some  operational-related  format  as 
follows ; 


PRIORITY  CONDITION  COMMENTS 


1st  CRITICAL 


2nd  IMPORTANT 


3rd  AUXILLIARY 


■'Uh  AIDING 


Arousal  Checklist  Questions 


represe:jts  a threat  to 

HUf-IAN  SAFETY,  AND  NEEDS 
IMMEDIATE  ATTENTION  FOR 
CORRECTION 

REPRESENTS  A THREAT  TO 
PFIYSICAL  PLANT  INTEGRITY, 
AND  NEEDS  IMMEDIATE 
ATTENTION  FOR  CORRECTION 

REPRESENTS  A THREAT  TO 
THE  EFFICIENCY  OR  OPTI- 
MIZATION OF  THE  PROCiSS, 
AND  NEEDS  ATTENTION 

REPRESENTS  HELPFUL  OR 
SUPPLEMExNTARY  INFO.,  \fflICH 
DOES  NOT  NEED  TO  BE 
ACKNOWLEDGED 


1.  Is  alarm  based  on  absolute,  differential,  or 
rat e-of- change? 

2.  Are  threshold  detection  limits  fixed,  variable, 
suppressable? 

3.  Are  alarms  structured  for  hierarchical  consi- 
deration? 

U.  Are  start-up  and  shut-down  false  alarming 
suppressed? 

5.  Is  operator-prompting  a part  of  the  alarm  sys- 
tem? (expectations) 
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6.  Are  alarm  outputs  on  multipurpose  devices  or  on 
dedicated  displays  and  devices? 

7.  Is  noise-filtering  or  statistical  support  pro- 
vided? (validation) 

8.  Is  pre-alarm  recording  available?  (for  DECISIO’J- 
MAKING) . 

9.  Is  alarm  system  hardwired  or  automat  d?  (com- 
puter) 

10.  Is  there  a back-up  system?  (for  what  other 
human  senses? ) 

11.  What  is  the  average  and  instantaneous  percep- 
tion loading?  (noise,  glare,  S/'J  ratio,  envi- 
ronment. . . . ) 

3.2.4  Response  Time 

Once  the  arousal  threshold  has  been  reached,  and  the 
operator  is  aware  of  a new  input,  information  processing 
can  proceed.  The  delay  between  the  input  condition 
sufficient  for  perception  and  a measurable  output  is 
defined  as  the  operator's  response  time. 

The  actual  value  of  response  time  is  extremely 
dependent  upon  the  type  of  encoding  and  accuracy 
required  in  any  resultant,  measurable  output.  The 
response-time  flow  is  as  shown: 


PERCEPTION  ■ 


• COGNITION  - 


• PROCESSING - 


AROUSAL  LAC 


COGNITION  LAG  PROCESSING  OUTPUT 

TIME  LAS 


Some  of  the  recognizable  cognition  affectors  are: 

-Amount  of  extraneous  information  (noise) 
-Strength,  quality,  uniqeness  of  information 
(errors ) 

-Motivation  (commitment,  duty,  interest,  pay- 
off) 

-Physical  and  mental  condition  of  man 

-Type  of  perception  involved 

-Type  of  encoding  (sequence,  time,  space) 

-Previewed  information  (trending,  modeling) 

-Qualilative  vs.  quantitative  input 

-Skill,  training,  experience 

-References  and  aids 


Some  of  the  recognigable  processing-time  affecto 
are: 


priority-weighting  and  decision  making, 

prioritity  of  task  as  related  to  priority  of 
goals 

■experience  and  accuracy  of  memory  models  and 
algorithms 

■whether  generalized  algorithm,  infrequently 
used;  or  specialized  algorithm,  frequency 
used 

■workload  and  stress 

anticipation  of  event  (look  ahead  technique) 
■accuracy  of  desired  output  (re-iteration  and 
checking  may  be  required) 

■consequences  of  errors  (pay-off  motivation?) 
decision  aids  and  back  up  information  avail- 
ability (for  decoding-enhancement  and  re- 
dundancy) 

■type  of  processing  (addition,  multiplication 

are  faster  than  subtraction,  division;  mis- 
sing element  detection,  or  exceptional-element 
detection,  etc.) 

validity  of  information  or  data  items,  or 
deduced  probabilities  of  events 


■time  span  of  task,  timing  of  feedback 

■speed  requirements 

■motivation 

■references 

■feedback  (speed  and  quality)  for  re-iteration 
■training,  skill 
■physical  and  mental  condition 
■resolution  of  output  required  compared  to  re- 
solution of  input  data 

■methods  of  measurment , accuracy-verificat ion- 
validity 
-instriiment 
-supervisor 
-model  for  comparison 
-differential  or  absolute 


3.2.5  Workloading 


A man's  workload  can  be  defined  as  the  measureable 
(real  work)  output  plus  his  internal  or  mental  work 
load.  We  are  mainly  concerned  with  his  mental  work^ 
load  since  his  physical  work  output  requirement  is 
usually  negligible. 


Mental  workload  consists  of  all  mental  processing, 
whether  it  ever  2’esults  in  an  output  or  not,  and 
whether  or  not  is  was  stimulated  by  a real  or  imag' 
inary  input  or  stressor. 


Workloading  can  only  be  measured  indirectly  as 
related  to  a loss  of  thru-put,  processing  speed, 
and  accuracy.  Thru-put  in  turn  can  be  defined 
as  the  relative  measure  of  useful  information- 
output  of  an  operator,  as  related  to  the  information- 
input  required  to  produce  it. 

The  most  obvious  and  severe  workloads  on  an  operator 
are: 

- unnecessary  decoding  and  encoding  (trivia) 

- unnecessary  perception-filtering  due  to 

excessive  noise  on  inputs 

- unnecessary  output  requirements  (when 

machine-aiding  is  available) 

- stress  during  upsets  due  to  anticipated 

work  and  consequences  of  errors 

- decision-making  due  to  imperfect  data 

(unknown  validity) 

By  "unburdening"  the  operator,  you  can  selectively: 


1.  reduce  training  time 

2.  reduce  required  skill  or  capacity  level 

3.  reduce  errors 
increase  safety 

5.  increase  operator's  reserve  resources 

6.  increase  consistency  of  behavior  and  operation 


You  can  do  this  by: 

1.  making  displays  and  controls  compatible  (trans- 
parency) 

2.  augmenting  operator's  less  efficient  talents 

3.  reducing  trivia 

data  buffering,  queueing,  filtering 

5.  hierarchical  alarming 

6.  aided  statistical  suramaries/analysis/modeling 
T.  enhanced  decision-making  using  information- 

validity  flags 


Or  an  operator  will  do  it  automatically  by: 

1.  omis  Sion  of  his  less  critical  tasks 

2.  allow  errors  to  increase 

3.  allow  efficiency  to  drop  back 

I4.  reduce  resolution  and  discrimination 

5.  reduce  responsiveness  by  increasing  his 
control-lag  and  dead-band 

6.  changing  mode  of  operation  to  relei ve  his 
pressure 

J.  assumming  validity  states  which  favor  easy 
decisions 


Work-Loading  ChocKlist  Questiom 


What  in  the  type  or  .workload  on  the  operator? 
-anticipatory  (threat  of  crisis) 

-actual  (physical,  mental) 

-stress  (threat  to  personal  life  style) 


Is  operator's  job  designed  around  maximizing 
thru-put  or  maximizing  reserve  capacity  for 
emergency? 


Is  operator' s task  to  involve  maintenance? 
Exercises  and  drills?  Data  Logging? 


Are  the  social-interaction  pressures  identifiable? 


What  type  of  memory  loading  is  involved? 
-short  term 
-long  term 


What  type  of  decision  making  is  involved? 
-amount  of  mental  stress 
-validity  of  information 


What  type  of  operation  is  involved: 

-open  loop,  predictive,  adaptive  control 
(pursuit ) 

-closed  loop,  (compensatory) 

-operation  by  exception  (monitoring) 


What  is  the  quality  and  quantity  of  data  display? 
of  control?  of  feedback? 


9.  What  are  the  learning  requirements  on  operator? 


on  operator  to  furnish  dsta 


ire  requirement 


amount,  quality,  type,  method,  timing 
■consequences  of  default,  error 


Are  consequences  of  work-load  reduction  most 
important  because  of  man's  comfort,  performance 
requirements,  or  safety  requirements? 


What  type  of  timing  is  involved? 
Man-pace-machine,  or  machine-pace-man? 


3.2.6  Encoding/Decoding 


All  information  presented  to  an  operator  is 
encoded  in  some  form  of  spatial,  temporal,  sequen- 
tial, or  operational  relationship.  Likewise,  all  of 
the  operator's  output  is  encoded.  It  is  of  utmost 
importance  to  keep  this  encoding  to  a minimum,  and 
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to  have  that  minimum  closely  matched  to  the  opera- 
tional requirements  of  workload, ^ accuracy , and 
response  time. 

The  most  straightforward  encoding  techniques  are 
said  to  be  "transparent" , while  more  highly  encoded 
information  is  said  to  be  "noisy"  and  contain 
"trivia". 

A "sterotype"  is  merely  a realization  of  a specific 
encoding  set  of  conventions  and  models  of  the  real 
world  environment  as  relating  to  objects,  ideas, 
processes  and  so  on.  It  is  dependent  upon  regional 
populations,  language,  vocabulary,  social  status, 
education,  etc. 

It  should  be  noted  however,  that  a certain  minimum 
amount  of  encoding  and  trivia  is  necessary  to 
maintain  some  degree  of  realism  and  operator 
interest,  and  also  to  provide  a certain  uniqueness, 
or  personality  or  "character",  for  separate  entities 
of  the  MMIF. 

As  an  example  of  the  use  of  encoding,  consider 
alarming.  In  a parrallel-board  array  where  all 
alarm  indicators  and  interaction  switches  are  pre- 
sent at  all  times,  the  operator  has  little  need  of  n 
mental  model,  since  he  can  relate  the  necessary 
response-algorithms  directly  to  the  spacial  location 
of  an  alarm.  He  mentally  stores  his  algorithm  in 
the  appropriate  spatial-location  of  the  alarm  panel. 
If,  however,  the  panel  is  large  or  only  occassionally 
used,  it  will  be  helpful  to  provide  secondary  or 
"prompting"  information. 

Now  consider  when  this  alarm  panel  is  automated 
and  put  on  a CRT  display,  with  computer-aided 
hierarchy.  Now  an  alarm  appears  on  a CRT,  and 
the  operator  must  read  it , decode  the  language, 
and  mentally  match  the  message  with  the  appropriate 
response.  Response  time  is  slower,  and  the  workload 
is  higher.  If  it  were  a "critical"  level  alarm, 
this  would  be  a poor  design.  If  it  were  a "helpful" 
level  of  message,  no  harm  is  done. 

As  another  example  for  a CRT  display  or  diagram, 
consider  a valve-symbol  or  callout.  The  encoding 
of  the  symbol  by  shape,  orintation,  size,  inten- 
sity, or  color  could  indicate: 

- is  the  valve  open  or  closed? 

- is  it  in  manual,  or  local,  or  computer  mode? 

- is  it  in  a faulty  mode? 

- is  it  in  a state-of-maintenance? 

- is  it  being  by-passed  for  some  reason? 

- is  it  in  standby? 

- is  the  data  or  indication  valid  (confirmation 
required ) . 
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VThere  would  I'urther  details  be  available  if 
the  valve  symbol  Itself  did  not  give  its  entire 
status? 

- in  a general  purpose  data  base  called  by 

a general  purpose  program,  keyed  entry? 

- by  certain  action  on  the  valve  symbol  itself? 

- on  a bulletin  board? 

- on  a supervisor's  clip  board? 

- on  a shift  logbook? 

- verbally  from  another  operations  person? 

- by  off-line  communications  to  other  personnel, 

must  then  visually  inspect  the  valve  for  you? 

Also  consider  for  a CRT 

- what  happens  when  an  operator  enters  an  error? 

- when  he  repeats  an  entry? 

- when  he  omits  an  entry? 

3.2.7  Job  Aids 

Job  aids  are  of  value  not  only  to  relieve  the 
operator  of  heavy  workloads,  but  also  to  improve 
his  accuracy  and  response  time.  Aids  can  be 
provided  to  assist  him  with: 

- time  references  (provide  event  indicators,  trend 

charts ) 

- spatial  references  (provide  models,  graphic 

panels) 

- operational  sequence  references  (provide  graphic 

panels, encoded  prompting  information.) 

- short-term  memory  references  (provide  strong 

feedback  and  status  information  updated  rapidly) 

- long-term  memory  (provide  bulletin  boards, 

notes,  indexes,  drawings,  pictures,  reference 
manuals ) 

- decision  making  (provide  historical  and  trending 

data,  precendents,  model  situations,  predictive 
or  fast-modeling  information. ) 

- information  processing  (provide  scaling  or 

calculating  or  normalizing  information  so  that 
it  is  qualitative  rather  than  quanitative) 

- quantitative  evaluations  (provide  time  compres- 

sion or  expansion,  differentiation,  integra- 
tion, spatial-compression  or  expansion,  or 
useful  rearrangement  by  intentional  distortion, 
so  that  the  operator  can  use  comparison  for 
evaluation) . 

In  addition,  the  job  aids  could  be  manuals,  proce- 
dures guidelines,  policies,  optimization  data  for 
the  process  as  well  as  for  operational  modes,  opti- 
mization goals,  etc. 
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3.2.8  Training 

Training  is  simply  a collection  of  methods  or  procedures 
used  to  selectively  increase  specialized  skills  of  a 
person.  This  is  usually  specified  for  a specific  Job 
requirement,  and  itT  is  expected  to  be  an  efficient 
process.  (Education,  on  the  other  hand,  is  defined  as  a 
more  generalized  program  to  increase  reasoning,  analysis 
and  decision-making  skills  in  a broader  fashion;  and  is 
not  expected  to  be  an  efficient  or  goal-directed  process 

The  broad  objectives  of  Training  are  to: 

- increase  skills  (physical  and  mental) 

- decrease  errors  (increase  reliability) 

- increase  thruput  (decrease  response  lag) 

- enhance  accuracy  (resolution) 

- increase  motivation  (self-confidence,  duty) 

- increase  capacity  (reserve) 

The  two  obvious  modes  of  training  are: 

1.  ON-LINE 

On-line  training  is  possible  only  when  man 
is  pacing  or  scheduling  the  machine,  and  errors  are 
reversible  and  non-critical . 

The  training-aids  or  job-aids  could  be: 

- Documents,  manuals,  charts, 

- Procedures,  nomographs 

- Background-mode  computer  simulation 

The  training-aids  design  will,  require: 

- Definitions 

- Requirements  of  system  & 

performance  criteria 

- Orientation  infomation  (models, 

diagrams,  theory) 

- Procedures  (operations-sequence , policy) 

- References  and  listings 

2.  OFF-LINE 

Off-line  training  is  required  when 
the  machine  paces  the  man,  errors  are 
irreversible  and  critical,  and  high 
resolution  or  accuracy  is  required. 

The  training  aids  are  likely  to  be: 

- Films,  simulators,  recordings, 

- Closed  circuit  TV,  teaching  machines 

The  training  aids  design  will  require: 

- Process  simulation  or  realism, 
including  projected  consequences  of 
cr*'or . response  time,  accuracy, 
feeUbacK  information. 
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3.2.9  Psychological  "Fit" 

Here  we  are  concerned  with  the  psychological  "fit"  of  the 
MMIF  to  the  operator.  All  of  the  previously  mentioned 
factors  and  categories  come  to  bear  in  one  final  and 
composite  "feeling"  that  the  operator  will  have  towards 
the  machine. 

Regardless  of  the  success  of  the  individual  aspects  of 
the  MMIF,  if  this  overall  and  sub.lective  "feeling"  of  the 
operator  toward  the  achine  is  negative,  the  project  is 
doomed  to  failure  — or  at  the  least  doomed  to  the 
seairching-out  of  an  operator  who  will  "fit"! 

The  purpose  of  the  Guideline  in  this  area  is  to  make  you 
aware  of  the  aspects  of  this  problem,  the  implications  it 
can  have  on  your  project,  and  possible  sources  of  further 
information  on  the  subject  (like  the  Bibliography). 

An  example  will  be  given  regarding  the  concept  of  "pacing" 
to  illustrate  the  subtle  effects  of  the  psychological 
"fit"  of  the  machine  to  the  operator. 

A man  is  said  to  be  "paced"  by  the  machine  if  he  has 
little  choice  of  what  to  do,  and  how  to  do  it,  and  when 
to  do  it.  He  in  effect  is  acting  as  a captive  closed- 
loop-controller.  On  the  other  hand,  man  is  said  to  be 
"pacing"  the  machine,  if  he  decides  on  his  own  what  to 
do,  how  to  do  it,  and  when  to  do  it. 

Man  rarely  if  ever  likes  to  be  paced  by  a machine  (the 
only  obvious  exceptions  are  competitive  "games").  When 
he  is,  he  can  feel  "threatened"  or  "crowded"  by  the 
machine,  and  this  would  be  a bad  psychological  "fit".  On 
the  other  hand,  if  the  man  felt  he  was  pacing  the  machine, 
always  understood  it , and  felt  he  was  always  in  command , 
this  would  be  a good  psychological  "fit". 

Let's  examine  some  aspects  of  the  MMIF  which  affect 
pacing. 

During  smooth  operation  of  a plant  running  under 
management-by-exception,  man  is  "pacing",  generally. 

During  emergency  upsets,  the  machine  could  easily 
pace  the  man,  unless  the  computer  is  used  to  support 
him  by  hierarchical  alarming  algorithms,  automated 
recovery  routines,  operational  guideline  information, 
and  so  forth. 
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Dixring  routine  operations,  if  the  machine  is  automated 
to  the  extent  that  a display  tells  the  operator  what 
to  do,  how  to  do  it,  and  when  to  do  it  (like  with  a 
"programmed-text-book"  approach  and  variably-assigned 
displays  and  controls,  so  that  he  is  only  given  a 
selected,  pre-defined  set  of  data  and  controls)  he 
could  feel  "paced".  This  could  be  avoided  by  "open- 
ing-up" the  automated  scheduler,  so  that  the  man  could 
maintain  freedom  of  the  overall  direction  of  the 
program,  and  escape  or  maneuver  within  it  freely  by 
his  own  choice. 

- When  entering  a command  to  display  or  control  a 
particular  variable,  the  man  couid  feel  paced  or 
"crowded"  if  he  had  to  serially  type-in  a rather 
lengthy  or  complex  string  of  characters  in  a rigid 
format,  especially  if  the  machine  stops  him  instantly 
upon  making  a small  error  such  as  a software  detect 
able  syntax  error,  for  example. 

In  summary  then,  the  computer  should  augment  the  .’'TIIF  to 
such  an  extent  tiiat  the  operator  is  effectively  relei ved 
of  busywork  or  pacing  activities,  and  is  given  tiie 
impression  that  he  is  in  command  of  the  machine  at  all 
times.  He  must  never  be  "trapped"  or  "paced"  by  the 
machine;  operators  who  are  will  tend  to  revert  to  their 
preferences  of  "traditional"  wallborads  of  control; 
operators  who  have  favorable  experience  under  computer 
automation  will  actively  participate  in  furtiier  auto- 
mation activities. 

3.3  Translator  Functional  Requirements 

In  these  guidelines,  the  term  "Translator"  is  used  to  re- 
present the  totality  of  hardware  and  software  in  the  MMli’ 
through  which  operators  and  process  communicate  with  each 
other.  Information  and/or  action  flows  through  the  NBIIF  froir : 
-translator  to  man 

-man  to  translator 

-1  Translator-to-Man  Requirements 

This  subsection  examines  the  functional  requirements 
imposed  on  the  translator  by  the  operator's  need  for  data 
presentation. 

- Degree  of  Serialization  of  Data  Presentation 


In  the  past,  process  control  interfaces  have  charac- 
teristically provided  the  operator  with  all  the 
information  into  and  out  of  tiie  system  in  a simul- 
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taneous,  parallel,  data  presentation.  As  systems 
grew  in  complexity,  it  became  obvious  that  the  human 
mind  had  a finite  data  processing  rate  along  with 
the  realization  that  the  operator  may  well  be 
overlooking  key  inputs  due  to  the  overwhelming 
amount  of  data  presented.  Modern  interfaces  tend  to 
reduce  this  mass  of  data  into  a more  manageable 
form,  by  presenting  the  operator  with  only  the  data 
he  requires  soon  for  carrying  out  the  specific  task 
confronting  him.  This  is  termed  a "serial  operator 
interface",  and  the  mode  of  selectively  outputting 
preprocessed  information  is  known  as  "management  by 
exception".  Management  by  exception  implies  that 
only  off-normal  data  will  be  presented  to  the 
operator,  thereby  allowing  him  to  concentrate  his 
attention  on  current  critical  requirements  of  the 
system. 

In  designing  such  a system  it  is  necessary  to  estab- 
lish a hierarchy  of  data  presentation  to  allow  the 
operator  to  quickly  access  the  actual  loop  or  point 
to  which  he  wishes  to  direct  his  attention.  This 
may  be  accomplished  by  having  the  operator  normally 
monitor  a very  macroscopic  view  of  the  process  and 
then  quickly  and  conveniently  focus  or  "zoom-in"  on 
the  trouble  spot.  This  technique  efficiently 
overcomes  the  lack  of  simultaneous  data  display. 

Such  interfaces  may  still  retain  elements  of  paral- 
lel data  display.  For  example,  several  CRT  displays 
may  be  located  on  a console  to  allow  the  operator  to 
keep  a running  summary  of  alarms  always  in  view  on 
one  CRT,  with  a second  CRT  showing  the  trend  of  some 
group  of  troublesome  points,  and  a third  CRT  used  as 
a "utility"  screen  to  call  up  those  additional 
displays  he  needs  for  the  ongoing  monitoring  and 
control  of  the  process. 

Information  Availability 

Depending  on  the  needs  of  the  operator,  the  informa- 
tion may  be  made  available  by  the  translator  in  any 
of  four  modes: 

- Continuous 

- Periodic 

- On-demand 

- Automatic 

The  most  critical  functions  may  be  required  by  the 
operator  on  a continuous  basis  and  this  implies 
dedicated  presentation  hardware. 
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Examples  of  periodic  data  requirements  are  found  in 
hourly  logs  of  all  or  groups  of  system  parameters. 
This  may  well  require  a hard  copy  display  for 
records  of  system  performance. 

On-demand  presentation  would  form  the  basis  for 
selective  call-up  of  variables  that  are  normally  of 
low  importance,  and  this  method  requires  the  minimum 
investment  in  display  hardware  due  to  the  time- 
sharing possibilities. 

Automatic  presentation  of  data  is  one  of  the  most 
important  techniques,  as  it  is  implicitly  required 
by  the  management-by-exception  technique.  In  this 
mode  the  event  is  called  up  by  the  abnormality  of 
the  event  itself.  An  example  is  a data- scanning 
system  which  outputs  messages  automatically  when  a 
point  goes  into  alarm.  As  the  quantity  of  aata  is 
not  totally  predictable  as  in  the  other  modes, 
.methods  such  as  providing  multiple  CRT  pages  or 
hierarchical  buffering  must  be  used  to  handle  a 
situation  where  many  alarms  can  occur  before  the 
operator  can  process  them. 

- Flexibility 

Flexibility  refers  to  the  capability  of  the  tj-ans- 
lator  to  grow  with  the  system  and  to  provide  a meaiis 
by  which  the  system  attributes  may  be  reconf  igui’ed . 
An  example  is  found  in  systems  permitting  on-line 
modification  of  graphic  CRT  dlagram.s  such  as  process 
schematics  and  pictorials.  In  these  systems  ttie 
operator  or  programmer  calls  up  the  format  to  be 
modified  and  types  in  the  ciianges  from  iiis  keyboard. 
When  all  modifications  have  been  entered  tlie  opei-a- 
tor  pushes  a button  calling  up  a special  program 
that  stores  his  new  diagram  for  future  use.  By 
these  means  the  operator  can  rapidly  alter  his  data 
presentation  to  keep  it  cui’rent  with  the  state-of- 
the-process,  and  is  an  advantage  unique  to  the  CRT- 
based  oper’ation  interfaces. 

Another  example  of  flexibility  is  fournl  in  transla- 
tor designs  that  permit  the  data  to  be  reconfigured 
into  different  combinations  that  are  meaningful  f^r 
the  specific  task  at  hand.  For  example,  various 
process  variables  could  be  assigne.i  to  a CRT  bar- 
chart representing  their  current  value  or  their 
setpoint  deviation. 


1 

i 


\ 


j' 

5; 


J.; 

r 

V. 


w 


1 


i 


I- 


3.3.1 


I 


I 


I 

1 


-U3- 


The  more  flexiblity  built  into  the  translator  the 
greater  will  be  its  ability  to  adapt  to  future 
system  needs.  This  must  be  balanced  against  in- 
creased translator  design  complexity,  processing 
power,  and  programming  requirem.ents . 

- Operator  Aiding 

The  most  generalized  requirement  for  a convenient 
interface  design  is  to  bring  the  data  to  the  opera- 
tor, not  the  operator  to  the  data.  The  data  should 
be  arranged  to  minimize  or  eliminate  the  need  to 
refer  to  look-up  tables  for  interpretation  of 
scaling,  linerization,  operating  procedures,  start 
up  or  shut  down,  etc.  The  alarm  messages  may  pre- 
sent not  only  the  time,  date,  point  number,  and 
nature  of  the  alarm,  but  may  also  give  the  operator 
action-oriented  instructions  to  guide  him  through 
the  necessary  corrective  measures.  Also,  alarms  may 
be  classified  as  to  degree  of  importance  to  help  the 
operator  quickly  decide  what  action  is  most  criti- 
cal. 

- Readability 

Operator  acceptance  of  the  control  room  equipment  is 
tied  strongly  to  the  readability  and  display  clarity 
of  the  display  system.  Included  here  we  have  consi- 
derations involving  readability  at  normal  viewing 
distances,  absence  of  flicker,  and  proper  control 
room  ambient  lighting. 

Display  readability  also  involves  proper  differ- 
entiation of  data  classes  through  the  use  of  color, 
character  size  and  shape,  and  well  organized  group- 
ings of  data. 

- Comprehension 

Operator  comprehension  of  data  benefits  greatly  from 
the  management-by-exception  principal,  in  which  the 
only  data  presented  is  that  needed  by  the  operator 
at  that  moment.  This  technique  effectively  mini- 
mizes "sensory  overload",  which  can  occur  in  trans- 
lator designs  that  output  excessive  amounts  of  data 
simultaneously . 
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Another  key  attribute  for  furthering  comprehension 
Is  to  arrange  the  presentation  of  information  to  be 
as  intuitive  as  possible.  Examples  are  in  the  use 
of  trend  recorders  to  graphically  show  process 
variations  over  a period  of  time  rather  than  period- 
ically printing  out  digital  values  of  the  variable. 
Also,  CRT  graphic  diagrams  can  be  configured  to 
indicate  a pictorial  diagram  of  the  plant  or  a 
section  of  the  process,  and  chow  key  real-time  data, 
for  variables  adjacent  to  the  appropriate  symbols  of 
the  variable.  Thus  the  intuitive  grasp  of  the 
system  is  increased  by  showing  such  variables  as 
tank  levels  pictorically  as  well  as  digitally. 

(i.e.  qualitatively  as  well  as  quantitatively.) 

- Reliability 

Translator  reliability  may  be  greatly  improved  by 
providing  redundant  information  display  capability 
at  every  operator  location.  For  example,  an  oper- 
ator may  have  two  CRT  displays  at  a console,  and 
would  normally  use  both.  In  the  event  of  a failure 
of  one,  the  other  would  furnish  the  most  critically 
needed  displays.  In  any  event,  no  single  failure 
should  totally  take  down  the  MMIF  station. 

- Throughput 

The  throughput  requirements  of  the  translator  are  a 
function  of: 

- The  amount  of  presentation  hardware 

- The  frequency  of  presentation 

- The  presentation  procecsin.g  requii'ement  s 

- The  control  room  layout 

For  exautiple,  as  the  number  of  d.i  splays  and  displtiv- 
update  rates  increase,  the  bui'den  on  the  translator 
likewise  increases.  The  type  of  displays  used  also 
impacts  the  translator  processing  requirement  with, 
for  example,  CRT  displays  imposing  a greater  burden 
than  in-line  digital  indicators.  Also,  various 
classes  of  CRT  displays  impose  different  throughput 
requirements  on  the  translator,  witli  random-scan 
displays  normally  needing  more  processing  power  than 
raster-scanning  displays.  The  control  room  layout 
will  also  influence  translator  tliroughput  if  some  of 
the  work  stations  are  so  far  removed  from  the  trans- 
lator processing  equipment  that  relatively  slow  data 
transmission  techniques  must  be  employed  to  transfer 
the  data.  The  throughput  at  these  "re.mote"  loca- 
tions will  be  more  difficlut  to  handle  in  that  case. 
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3.3.2  Man- To- Translator  Requirements 

This  subsection  examines  the  functional  requirements 
imposed  on  the  translator  by  the  need  for  operator  inter- 
action with  the  process  through  the  translator. 


- Degree  of  Interaction  Required 

The  sophistication  of  the  system  hardware  and  soft- 
ware required  to  provide  operator  interaction 
depends  primarily  on  how  often  the  operator  must 
interact  with  the  process  through  the  MMIF.  Sophis- 
tication is  also  highly  dependent  upon  the  crit- 
icality of  that  interaction  and  upon  what  stresses 
are  imposed  on  the  operator.  Obviously  the  more 
often,  the  more  critical,  and  the  more  stressful  the 
situation,  the  greater  will  be  the  need  for  a 
translator  design  which  permits  rapid,  accurate,  and 
convenient  control  over  the  process. 

- Classes  of  Interactive  Hardware 

Interactive  hardware  may  be  either  dedicated  to  a 
particular  point  or  shared  among  many  points.  This 
ties  in  closely  with  the  degree  of  serialization  of 
translator  hardware  as  covered  in  the  preceeding 
subsection  on  translator-to-man  requirements. 

Modern  translator  implementations  tend  toward  more 
shared  hardware  with  the  exception  of  critical 
safety  systems,  which  may  be  dedicated  to  a parti- 
cular purpose. 

- Degree  of  Serialization  of  Translator 

As  mentioned  under  the  translator-to-man  subsection, 
modern  operator  interfaces  tend  toward  a much 
greater  degree  of  serialization  of  data  display  than 
in  the  past.  This  impacts  on  operator  interaction 
because  frequently  the  interaction  will  be  accom- 
plished via  the  same  serialized  data-presentation 
hardwaie.  An  example  would  be  calling  up  graphical 
"pages"  of  displays  on  the  CRT  one  at  a time,  to 
operate  valves  and  breakers  by  direct  interaction 
with  symbols  within  each  display. 

- Requirements  Imposed  by  Interactive  Devices 

Speed  - There  is  a wide  range  of  speed  at  which 
available  interactive  devices  operate.  An  example 
would  be  positioning  the  cursor  on  a CRT  display  via 
a keyboard  equipped  with  keys  that  can  move  the 
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cursor  up,  down,  right,  or  left  one  step  at  a time 
(slow);  a trackball  or  joystick  control  which  can 
move  the  cursor  at  variable  rates  along  any  vector 
(intermediate);  and  light  pen  control  which  can 
position  the  cursor  randomly  to  any  point  on  the 
screen  (fast).  The  relative  speeds  of  the  devices 
mentioned  have  not  considered  the  time  it  takes  the 
operator  to  move  his  hand  to  that  device,  and  that 
too  must  be  considered! 


Accuracy  - Obviously  the  benefits  of  fast  operation 
of  an  interactive  device  will  be  lost  if  the  device 
does  not  operate  accurately  or  consistently.  This 
will  be  especially  important  during  times  of  stress 
when  such  deficiencies  are  magnified.  An  example 
would  be  using  a light  pen  that  will  not  position 
the  c\irsor  accurately  to  the  target  area.  To  a 
certain  extent  the  implementation  of  system  design 
should  compensate  for  the  inherent  limitations  of 
interactive  devices.  (For  example,  providing  the 
operator  with  a larger  light  pen  target  for  import- 
ant interactions). 

Convenience  - The  same  concepts  of  operator  conven- 
ience as  described  under  "readibility"  must  again  be 
considered  when  designing  MMIF  interaction  methods. 
This  point  is  especially  important  with  regard  to 
operator  acceptance  of  the  system.  The  designer 
must  take  into  account  the  requirements  of  accxiracy 
and  speed  mentioned  above,  as  well  as  good  human 
engineering  of  the  interactive  hardware,  by  account- 
ing for  proper  physical  location  of  the  devices  as 
well  as  designing  a high  measure  of  "intuitive" 
operation  into  the  required  interactions. 

Effects  on  display  hardware  - The  requirement  for 
interactive  use  will  impose  a higher  level  of 
sophistication  on  the  display  hardware  by  the 
required  two-way  flow  of  information.  For  example, 
CRT  displays  may  require  that  the  contents  of  the 
screen  memory  be  capable  of  being  read  by  the 
computer  following  for  operator-initiated  data  and 
control  inputs. 


- Feedback 

Every  important  interactive  event  the  operator 
enters  into  should  be  confirmed  with  some  form  of 
feedback  to  signify  that  his  action  has  been  acknow- 
ledged. This  can  take  the  form  of  a color  change  on 
the  CRT,  a button  lighting  to  say  the  computer  is 
processing  his  entry,  or  simply  an  audible  or 
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tactile  feedback  signal  indicating  acknowledgement 
that  he  has  pushed  the  button.  Indeed,  it  is 
usually  important  for  the  operator  to  be  given 
feedback  for  each  level  of  operation  resulting  from 
his  input.  For  example,  acknowledgement  of: 

- the  proper  functioning  of  the  key 

(by  a clicking  sound) 

- the  computer  acceptance  of  the  request 

(by  a character  "typed"  on  the  CRT) 

- the  program's  acceptance  of  the  "new  datum" 

(by  a color  change  or  blink  of  the 
same  character) 

- the  proper  continuing  operation  of  a program 

(by  some  form  of  "system  heartbeat" 
display — for  example,  displaying  digital 
clock  time  updated  every  second) 
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It.  0 Implementation 

This  section  discusses  the  means  by  which  operators  exchange  infor- 
mation with  the  process  through  the  MMIF  by  consideration  of  the 
methods  of  MMIF  implementation.  There  are  two  functions  evolved: 

a)  Presentation  to  the  operator  of  information  about  the 
process  and  control  system  (alarms,  measurement  values, 
control  mode,  etc.); 

b)  Manipulation  by  the  operator  of  information  to  convey  his 
messages  to  the  process  (change  a set  point  value,  etc.). 

U . 1 Methodology 

This  section  emphasizes  a method  of  determining  how  to  imple- 
ment the  functions  of  presentation  and  manipulation.  It  does 
not  attempt  to  be  a catalog  of  available  devices,  or  a primer 
on  their  operation,  or  make  specific  recommendations  for 
particular  control  schemes  (set-point  control,  digital  control), 
or  of  particular  industry  applications  (petrochemical,  power, 
etc.).  The  intent  is  to  provide  the  designer  of  the  NjMIF  with 
a methodology  to  enable  him  to  select  or  specify  devices  to 
implement  a functional  solution,  versus  selecting  a device 
first  and  then  determining  what  can  be  done  with  it. 

This  method  has  three  basic  steps: 

a)  Task  - identify  the  presentation  or  manipulation 
task  (display  a set  point,  change  it); 

b)  Technique  - determine  alternate  functional  tech- 
niques which  will  accomplish  the  task; 

c)  Device  - identify  alternate  physical  devices  which 
can  implement  the  technique.  Functional  and  phy- 
sical capabilities  of  the  devices  must  be  considered 
to  determine  overall  usability  for  particular 
applications. 

- Personnel  Requirements 

For  purposes  of  discussion  in  this  section,  anyone  who 
uses  the  MMIF  is  considered  to  be  the  "operator",  al- 
though in  reality  he  could  be  some  other  type  of  per- 
sonnel. 

- Information  Exchange  Media 

The  media  through  which  information  is  exchanged  in 
conventional  analog  control  systems  are  single-purpose 
instruments  (controller,  recorder,  etc.)  which  are 
dedicated  to  particular  loops  by  hard-wired  connections. 
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The  instrument's  mechanical  format  determines  the  char- 
acteristics of  the  information  exchange  (content,  amount, 
full-value,  deviation,  etc.). 


In  contrast  to  these  conventional  systems  this  section 
assumes  that  the  primary  information  exchange  medium  is  a 
computer-control  system  with  a computer-driven  inter- 
active console  which  is  shared  among  all  loops.  It  is 
electronically  formatted,  under  program  control,  to 
perform  a variety  of  functions. 

- Emphasis 

Hence  this  section  emphasizes  the  usability  of  "nontradi- 
tional"  computer-driven  devices,  (such  as  CRT's,  key- 
boards, etc.,)  for  "traditional"  on-line  interactive 
process  control  activities  (like  "change  a set  point", 
etc.).  It  should  be  recognized  that  the  major  advantage 
of  these  computer-driven  devices,  namely  their  ability  to 
perform  nearly  any  presentation  or  manipulation  function 
through  program  design,  is  also  the  greatest  pitfall  to 
their  usability.  This  is  because  programming  must  be 
viewed  as  the  prominent  tool  to  make  the  device  reflect 
how  "real"  process-operators  work,  and  not  to  reflect  how 
programmers  prefer  to  create  interactive  displays. 

h.2  Presentation 


In  present  day  technology,  visual  and  audible  presentation- 
methods  are  the  only  techniques  widely  used.  It  is  recognized 
that  the  other  senses  (touch,  smell,  taste,  etc.)  are  employ- 
ed, however,  their  application  is  very  specialized  and  not  a 
topic  in  this  section. 

- Visual 


The  presentation  of  visual  data  to  the  operator  can  be 
broken  down  as  follows: 

- Variables  (i.e.  setpoint,  process) 

- Scales  (alarms,  auto/manual) 

- Tests  (operator  instructions,  loop  identification) 

- Diagrams  (flow,  schematic,  abstract  models) 

- Algorithms  (formatting  for  displays,  behavior 
for  controls,  configuration  for  control  systems) 

The  following  table  lists  the  various  presentation  tasks, 
applicable  techniques,  applicable  devices  and  comments. 


J 


TABLE  4.2 


-Extrapolation  Judgements  may  be  made, 
allowing  for  "anticipation"  of  behavior 


TABLE  4.2  (Cont. 


Multi  pen  recorder  -Good  resolution 
or  plotter 

-Limited  format 


TABLE  4.2  (Cont. 


-Inherent  recording  or  "logging' 


Presentation  Task  Technique  Devlee(s)  Comment s 
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“Difficult  Software  interface  unless 
auxilllary  controller  provided 
-Ron-remotable 

-Difficult  interface  required  for  hard  copy 
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- Audible 

The  use  of  audibles  in  conventional  systems  is  usually  i 

designed  to  interrupt  the  operator's  activity  and  either 
envoke  pre-determined  action,  e.g.  shutdown,  clear  area, 
etc.  or  direct  him  to  another  source  of  information,  e.g. 
look  at  annunciator,  read  teletypewriter,  etc. 

Through  the  use  of  audibles  having  different  character- 
istics, different  message  can  be  conveyed.  The  basic 
drawback,  however,  is  the  psychological  limitation  in  the 
amount  of  information  conveyable.  The  advantage  in  the 
use  of  audibles  is  that  the  operator's  hearing  function 
is  usually  unencumbered  and  a significant  sound  will 
interrupt  him  regardless  of  his  activity. 


Conventional  audibles  are  in  the  form  of: 
Harris  Horns 
Bells 
Klaxons 
Sirens 
Whistles 

Solid  state  such  as  piezo 
electric  devices 

- Voice  Response 


Unerging  in  present  technology  are  devices  which  will 
generate  human  speech.  Such  a device  obviously  opens  up 
a whole  new  communication  channel  to  the  operators 
without  the  limitations  of  the  previously  described 
devices.  One  such  device  converts  the  output  of  a 
computer  into  simulated  human  speech.  This  conversion 
from  digital  information  to  simulated  speech  is  accom- 
plished thru  design  which  divides  each  human  word  into 
phonemes,  such  as  vowels  or  consonants.  For  example,  the 
word  "hello"  consists  of  the  phonemes  "H",  "EH",  "L", 

"UH"  and  "0" . Each  phoneme  is  represented  by  a digital 
word.  These  phonetic  command  words  are  converted  into 
the  corresponding  phonetic  sounds  and  define  the  in- 
flection level  or  loudness  of  the  phoneme. 


h . 3 Manipulat ion 

Manipulative  devices  are  the  physical  means  by  which  the 
process  operator  transmits  his  commands  to  the  control  system 
and  process.  Hence  they  are  the  first  stage  of  translation 
from  "man  language"  to  "machine  language."  The  goal  in 


designing  the  manipulative  section  of  the  MMIF  should  be  to 
avoid  imposing  unnatural  machine-language  constraints  on  this 
initial  s|age.  Manipulative  actions  should  reflect  "plain 
English"  and  traditional  (stereotyped)  process-dependent 
terminology.  This  section  discusses  program-controlled 
maniptilative  devices  which  interact  with  electronically- 


. ...or  whatever  is  the  native  language  being  used! 
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formatted  display  devices  which  comprise  the  display  medium 
for  all  information  used  in  primary  on-line  control  operations 
(set  point,  measurement,  output  values,  control  status,  alarm, 
trend,  process  graphics,  logs,  etc.). 

These  devices  are: 

-Fixed- function  keyboards 
-Variable-function  keyboards 
-Light  pens 
-Touch  screens 
-Speech  recognition 

(note:  the  terms  "keys"  and  "buttons"  are  used 

interchangeably ) 

This  section  does  not  cover  hard-wired  devices  dedicated  to 
particular  functions  (motor-starter  pushbuttons,  etc.),  or 
directly  associated  with  ancillary  MMIF  equipment  (recorder 
patch  panels),  or  captive  controls  (recorder  chart  drive 
selector  switch,  hand  copier  on/off  switch  etc.). 

- Human  Manipulative  Senses 

The  human  motor-response  (hand-controls)  and  vocal  output 
response  are  highly  developed  for  directly  interactive 
control  tasks  (changing  controller  mode,  value,  etc.)  but 
are  commonly  overloaded. 

Human  vocal  output  has  been  used  mostly  to  supplement 
hand  controls  for  indirect  tasks  (relaying  information 
via  radio-telephone).  Recent  advances  in  computerized 
speech  technology  are  promising,  but  their  application  to 
directly  interactive  control- tasks  is  unclear.  Hand- 
operated  tactile  devices  are  dominant.  Those  suitable 
for  interaction  with  computer-driven  displays  are  light 
pens,  touch  screens,  and  various  types  of  keyboards. 
Foot-operated  tactile  controls  are  common  in  aerospace, 
machine-tool  and  vehicular  applications,  but  are  not  as 
frequently  or  as  effectively  used  in  the  primary  process 
industries  as  they  perhaps  co\ild  be. 
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- Devices  Descriptions 

Manipulative  devices  are  classified  as  variable- function 
or  fixed- function,  as  follows: 

Figure  k.3  Manipulative  Device  Classification 


Device 


Human 

Output 

Category- 


Functional 

Category 


Fixed  function  key 


Variable  function  key 
Light  pen 
Touch  screen 


Speech  recognition 


Motor 
response 
( Hand- 
operated) 


Voice 


Variable 


- Fixed-Function  Key 


A key  which  has  a single  dedicated  function,  identified 
by  a label  affixed  on  or  adjacent  to  the  key  top.  There 
are  two  general  types  of  fixed- function  keyboards: 

1.  Universal  format  (USASCII,  etc.) 


2.  Custom  format 


- Variable-Function  Key 

A key  whose  function  is  not  fixed,  but  varies  according 
to  display  conditions,  previous  action  of  another  key, 
etc . 

Variable- function  key  boards  utilize  a common  arrangement 
of  blank  (unlabelled)  keys  which  are  labelled  in  several 
ways ; 


-CRT  - keys  are  aligned  with  locations  on  CRT 
(usually  under  or  alongside  screen)  and  CRT  labels 
are  displayed  under  program  control 


i 


1 


i 


-Overlays  - sheets  on  which  labels  are  printed 
or  handwritten,  and  positioned  by  hand  to  be 
adjacent  to  or  over  keys  (with  or  without  cutouts 
for  keys ) 


¥ 
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-Shifting  - shift  or  "mode"  keys  are  used  to  change 
among  a fixed  set  of  alternate  functions,  labeled 
on  or  adjacent  to  keys  (examples:  Teletype,  keypunch, 
n\jmerous  hand-calculators ) 

-CRT  labelling  - the  most  flexible  and  powerful.  The 
number  of  labels  is  unlimited.  Operating  procedures 
can  be  completely  self-explanatory  (akin  to  pro- 
grammed textbooks ) wherein  current  labels  follow 
from  previous  actions.  "Illegal  actions"  can  be 
eliminated  by  displaying  only  labels  pertinent  to 
current  display  conditions  (type  of  loop  addressed, 
its  set  point  status,  etc.). 

Similar  techniques  can  be  used  with  light  pens  and 
touch  screens,  and  are  equally  flexible  and  power- 
ful. 


A light  pen  is  a hand-held  "active  stylus"  which  ad- 
dresses a position  in  a CRT  display  by  pointing  at  it. 
This  identifies  the  corresponding  CRT  beam  x-y  coor- 
dinates in  the  matrix  of  possible  CRT  beam  positions, 
which  is  then  decoded  to  determine  the  addressed  func- 
tion. 

The  light  pen  is  an  "active"  device  since  it  contains  an 
electro-optical  switch  which  responds  to  the  display's 
phosphor  limiinescence . A wire  carries  the  signal  from 
light  pen  to  decoding  circuitry.  The  CRT  beam  position 
matrix  is  "passive"  since  it  exists  only  as  a list  of 
addresses  in  computer  memory.  Appropriate  software  must 
be  provided  to  allow  "activation"  linkages  corresponding 
to  screen  coordinates  being  pointed  at  by  light  pen. 

Touch  Screen 


A touch  screen  is  essentially  the  inverse  of  a light  pen. 
It  uses  a "passive  stylus"  (finger,  pencil,  etc.)  for 
pointing  at  the  desired  display  position.  The  pointing 
actuates  one  electronically  sensitive  area  in  an  "active 
matrix"  which  is  deployed  over  the  display.  This  is 
decoded  to  determine  the  addressed  function  in  a manner 
similar  to  the  use  of  the  light  pen. 

The  switch  matrix  can  be  created  in  several  ways : 

-Mechanically  - crossed  (x-y)  wires  between 
transparent  plastic  sheets,  laid  directly  over 
the  display  surface;  actuated  by  pushing  wires 
together 
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-Optically  - visible  or  infrared  light  transmitters/ 
receivers  are  located  around  the  display  sur- 
face in  a "picture  frame";  actuated  by 
interrupting  the  light  beam 

-Acoustically  - similar  to  optical  but  uses 
sound  transmitters/receivers;  actuated  by 
an  acoustically-active  pen. 

-Electronically  - distributed  electrical  properties 
of  screen  are  precisely  balanced  by  electronic 
sensing  circuitry;  activated  by  touching 
screen,  upsetting  balance. 

In  any  event,  it  shoiild  be  noted  that  touch  screens  can 

be  used  with  any  display  medium;  they  are  not  a CRT-  i 

dependent  device.  Common  resolution  capabilities  are  to 

the  inch  or  CM,  but  resolutions  to  a few  thousandths  of 

an  inch  are  available. 

- Voice  Recognition 

Computerized  techniques  are  becoming  available  which  can  ; 

recognize  spoken  multisyllabic  words  and  phrases  with  : 

good  accuracy.  However,  numerous  restrictions  exist  on 
vocabulary,  training  of  machine  and  man,  etc.  This  i 

technique  has  been  used  mostly  in  nonprocess  control  ’ 

environments  where  the  motor  response  outputs  are  over-  ; 

loaded  (both  hands  full  loading  packages,  with  require-  ; 

ment  to  describe  package  to  a central  data  processing  | 

system),  or  not  available  (control  inputs  being  made  over  j 

a voice-communications  channel).  j 

Voice  recognition  could  be  useful  in  process  control  j 

situations  to  supplement  traditional  techniques,  and  v 

would  constitute  an  improvement  in  tasks  such  as  loop 
addressing  (it  should  be  easier  to  say  "display  FRClOO" 
than  to  type  in  at  least  six  alphanumeric  characters  or 
find  the  fixed- function  key  dedicated  to  that  loop).  Its 
usefulness  as  a general  purpose  or  primary  manipulative 
technique  for  all  actions  is  unclear  (it  is  more  compact 
to  manipulate  a "ramp"  button  to  adjust  a value  than  to 
say  "ramp  the  set  point  value  to  XXX. X at  a rate  of  Y" , 
and  then  interrupt  the  ramp  if  needed).  Also,  veri- 
fication of  voice  command  interpretation  would  be  needed 
prior  to  exectuion  of  the  command,  and  editing  and 
cancellation  methods  would  have  to  be  developed. 

- Evaluation  Factors 


Devices  must  be  evaluated  as  a medium  for  implementing  a 
technique  for  accomplishing  a manipulative  task.  Hard- 
ware design  should  follow  naturally  from  functional 
design. 


The  evaluation  process  has  an  objective/quantitative  side 
(which  devices  can  do  the  job  functionally  and  physi- 
cally?) and  a subjective/  qualitative  side  (which  fit 
best  into  the  overall  operating  procedure  philosophy? ) . 

A good  example  is  the  question  of  whether  to  choose  an 
optimum  device  for  each  task,  or  to  use  the  same  device 
for  all  tasks? 

On  the  objective/quantitative  side,  human  factors 
testing  can  demonstrate  that  human  performance  is 
clearly  superior  for  a certain  task  with  a certain 
device  (in  terms  of  accuracy,  speed,  repeatability, 
fatigue,  natural  hand/eye  coordination,  etc.)- 

On  the  subjective/qualitative  side,  however,  there 
are  strong  arguments  for  the  consistency  of  op- 
eration (hence  safety,  ease  of  training,  etc.) 
obtained  by  using  the  same  device  for  all  tasks.  It 
is  also  important  to  consider  how  the  device  affects 
(or  is  affected  by)  overall  work  station  charac- 
teristics (size,  shape,  standup/  sitdown,  etc.). 

Thus  the  most  important  attribute  to  a useful  overall 
solution  is  that  it  be  logical  (sensible)  and  natural 
(easily  learned  and  retained)  for  the  operator.  This  is 
usually  a better  solution  than  a collection  of  indi- 
vidually optimum  solutions. 


The  most  obvious  compromises  in  performance  between 
choosing  a fixed  or  dedicated-function  device  and  a 
variably-assigned- function  device  are  as  follows: 


-Dedicated  function — Once  the  operator  is  trained, 
he  can  exhibit  a very  short  reaction  time  ; 

in  the  use  of  the  device,  and  the  error 

rates  are  generally  very  low.  The  operator's  I 

short  term  memory  is  very  lightly  loaded  because  f 

the  devices  are  self-identified  according  J 

to  their  function,  and  thus  very  little  or  \ 

no  encoding  is  required.  The  disadvantage  5 

lies  in  the  inflexibility  to  change,  and  j 

the  tendency  of  dedicated  devices  to  proliferate  1 

and  require  extensive  layout  space.  A ; 

certain  point  can  be  reached  where  they  ) 

cover  such  a large  space  that  the  operator's  ; 

reaction  time  is  degraded  because  of  | 

search  time  and  long-term  memory  load! 

Errors  would  then  also  increase.  However,  i 

this  method  is  recommended  for  "critical  i 

controls"  because  of  the  likelyhood  of  J 

short-term  memory  overload  during  emergencies,  i 

but  especially  because  of  the  need  for  quick  response.  | 


i 
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-Variably  assigned  - Once  the  operator  is 
trained,  and  after  the  automated  assignment 
algorithms  are  optimized,  the  reaction 
time  and  error  rates  can  be  better  than  with 
dedicated  devices.  In  this  case,  the 
operator's  short-term  memory  is  required  to 
process  the  sequential  meanings  of  the  assignments, 
but  his  long  term  memory  is  effectively  releived 
by  the  automated  assignment  routines.  Therein 
lies  the  difficulty,  however,  in  the  critical 
need  for  thorough  software  design  and  evaluation. 
Once  that  is  handled  properly  however,  this  method 
exhibits  superior  flexibility,  and  compactness. 

One  must  be  careful  to  allow  appropriate  sequential 
controls  or  escape-mechanisms  into  the  algorithms, 
so  that  the  operator  doesn't  get  "trapped".  Also, 
this  method  might  not  be  appropriate  for  "critical" 
controls. 


Ij.U  Task/Technique  Characterization 

The  first  two  steps  toward  realizing  these  attributes  are: 

1.  Thorough  understanding  of  the  operator's  manipulative 
tasks  in  terms  of  the  type  of  manipulative  action  in- 
volved and  its  human  performance  characteristics; 

2.  Recognition  that  alternate  techniques  usually  exist  for 
accomplishing  each  task,  and  alternate  device  for  im- 
plementing each  technique. 


This  will  go  a long  way  toward  assuring  that  a single  tech- 
nique/device solution  is  not  "unnaturally"  or  "illogically" 
imposed  upon  all  task  problems.  Figure  U.U.l  illustrates 
these  two  points  for  the  example  information  organization  of 
Figure  U.U.2. 


TASK/ TECHNIQUE  CHARACTERISTICS 


U.5  Device  Usage  Characteristics 

The  next  step  after  identifying  task/technique  characteris- 
tics is  to  identify  alternate  devices  which  can  functional-  , 

ly  implement  the  desired  tef-hnique. 

1 

, 'I 

All  the  devices  covered  by  this  section  can  be  functionally  j 

interchangeable.  But  each  has  distinguishing  characteris- 
tics which  cover  the  gamut  of  human  factors,  physical, 
programming  support,  cost,  etc.  These  are  summarized  in 
Figures  1;.5.1  through  1*.5. 

The  evaluation  factors  above  can  now  be  applied  toward 
final  device  selections. 
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TOUCH  SCREEN  CHARACTERISTICS 


VOICE  RECOGNITION  CHARACTERISTICS 


EXAMPLE  EDUCATION  TREE 
(Illustrating  This  Method) 
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4.6 


The  philosophy  of  this  method  has  now  been  described  and  its 
component  parts  identified  for  selecting  manipulative  devices. 
Figure  4.6  pictorially  illustrates  the  train  of  thought 
involved  for  an  example  task. 
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5.0  Glossary 

Aesthetics  - A "quality"  concept,  relating  the  conformance 
of  an  item  to  some  preconceived  notion  or 
stereotype  of  the  same  item.  If  this  relationship 
is  favorable,  the  item  "fits  in",  and  is  said 
to  be  aesthetically  pleasing.  If  this  relation 
ship  is  disfavorable,  the  item  fails  to  fit, 
and  is  said  to  be  aesthetically  displeasing. 

Annunciator  - Self-contained  devices  used  to  indicate, 
but  not  record,  alarm  conditions. 

Arousal  Threshold  - The  level  of  an  input  and/or  the  time 

it  must  be  asserted  before  recognition 
occurs  by  the  operator. 

Bulletin  Board  Effect  - The  tendency  in  man/machine  control 

centers  of  using  all  available 
unused  panel  space  (and  writing 
surfaces)  for  offline  information. 

(ie.  operator  notes  and  messages) 

Clock  Shop  - The  appearance  of  a control  room  where  all 
of  the  walls  and  panels  are  covered  with 
meters,  dials  and  knobs. 

Cognition  - Preception-related  recall  from  long-term  memory. 

Compatability  - The  appropriateness  of  a display  to  a 

control;  also  of  a display  or  a control 
to  a task,  especially  related  to  the 
corre! lation  of  cause  and  effect.  True 
compatability  implies  less  need  for  trans- 
lation by  the  operator. 

Console  - The  machine  side  of  a man/raachine  interface 
(alternate  definition). 

Control  Room  - Any  center  of  activity  for  a manned  system, 
but  specifically  one  which  contains  a 
man/machine  interface. 

Display  - A visual  information  transmission  device  which 
is  driven  by  some  form  of  instrumentation 
(alternate  definition). 

Glyph  - Figure  or  symbol  used  as  an  abstraction  of  some 
physical  reality  or  event. 
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Iconic  Commiinication  - Communication  presentation  by 

visual  imagry,  especially  those 
which  move  and  change  with  time. 

Job  “ A set  of  tasks  assigned  to  some  person  (alternate 
definition) . 

Key  Operator  - A person  trained  and  responsible  for  a 
given  operation. 

Man/Machine  Interface  - The  interface  between  man  and  machine, 

where  man's  output  is  translated 
into  machine  input  and  vice  versa. 

Man/Machine  System  - A system  in  which  a man  is  a component 

and  a contributing  factor  to  the 
system  performance  (the  manned  portion 
of  a system  could  be  a considered 
sub-system) . 

Noise  - Any  input  to  a system  that  does  not  contribute 
to  the  usable  output  of  the  system.  (Alternate 
definition) . 

Off-Line  - Matters  indirectly  related  to  machine,  such 
as  documentation.  (Alternate  definition). 

On-Line  - Matters  directly  related  to  machine  in  "real-time" . 
(Can  be  man-to-man  commiinication) . (Alternate 
definition) . 

Preception  - Sensory  information  gained  through  the  use 
of  short-term  memory. 
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Population  Sterotypes  - Tradition,  convention,  or  commonly 

expected  behavior  or  characteristics. 
Associated  with  a particular  pop- 
ulation group  (for  example;  reading 
from  left  to  right,  top  to  bottom; 
right  handed  threads,  etc.). 

Sign  - A sign  is  any  information  display  which  is  not  con- 
nnected  to  instrumentation  and  is  never  interactive 
with  respect  to  feed-back  and  control.  (Alternate 
definition) . 

Task-  An  operation  to  be  accomplished  within  a system 

by  either  man  or  machine.  (Alternate  definition). 


Task  Analysis  - Analyzing  or  dissecting  what 
ally  being  accomplished,  and 
its  component  parts. 


is  function- 
classifying 


i 
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Task  Description  - Complete  item-by-item  specification 
of  the  individual  tasks,  which  taken 
together,  comprise  the  total  Job  activity 
of  the  operator. 


Task  Synthesis 


Assembling  the  individually  specified 
components  of  a function  in  order  to 
comprise  his  whole. 


Top  Down  - Abstracted  analysis  of  what  is  to  be  accomplished, 
without  arbitrary  constraint , but  rather  guided 
by  requirements  of  the  ultimate  end-result  or 
goal.  This  approach  requies  the  definition 
of  the  system  and  its  attendant  problems  before 
approaching  the  methods  of  solution. 


Trending  Recorder  - A data  recording  of  the  immediate 

past  behavior  of  a process.  Used  to 
extrapolate  the  behavior  of  the 
process  in  the  immediate  futiire. 

Trivia  - Apparently  arbitrary  representations  or  translations 
of  real  world  events;  anything  which  masks  or 
occludes  valid  information. 

Transparent  - That  which  is  intuitively  obvious  or  straight 
forward,  requiring  little  or  no  translation. 


...jm 
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5.1  SUPPLMENTARY  GLOSSARY 
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The  following  list  of  terms  are  used  in  the  general  area  of  the 
design  of  man/machine  interfaces  and  have  already  been  defined  by  the 
industrial  digiteil  computer  terminology  dictionary  prepared  by  the 
glossary  committee  of  Purdue  workshop  on  standardization  of  industrial 
computer  languages. 


Alarm 

Analog 

Backup 

Channel 

Communication 

Computer  Console 

Console 

Control 

Control  System 

Conversational  Mode 

CRT  Display 

Data 

Digital 

Display 

Emmulate 

Event 

Graphic 

Hard  Copy 

Hierarchy 

Information 

Interface 

Interlock 

Joy  Stick 

Loop 

Manual  Operation 

Mode 

Noise 

Off-Line 

On-Line 

Operator 

Optimize 

Plot 

Process 

Rank 

Record 

Reliability 

Remote  Stations 

Selection 

System 

Task 
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